On 02.07.19 17:01, Jan Beulich wrote:
On 28.05.19 at 12:32, wrote:
When running an idle vcpu in a non-idle scheduling unit use a specific
guest idle loop not performing any tasklets, memory scrubbing and
livepatching in order to avoid populating the cpu caches with memory
used by other domains
Currently, local and remote TLB flushes are not performed concurrently,
which introduces unnecessary overhead - each INVLPG can take 100s of
cycles. This patch-set allows TLB flushes to be run concurrently: first
request the remote CPUs to initiate the flush, then run it locally, and
finally wait f
To improve TLB shootdown performance, flush the remote and local TLBs
concurrently. Introduce flush_tlb_multi() that does so. Introduce
paravirtual versions of flush_tlb_multi() for KVM, Xen and hyper-v (Xen
and hyper-v are only compile-tested).
While the updated smp infrastructure is capable of r
On 02.07.2019 19:47, Andrew Cooper wrote:
> On 17/06/2019 09:12, Jan Beulich wrote:
>> Nothing (afaics) guarantees that the original frame's stack pointer
>
> I'd drop the (afaics), because the answer really is nothing.
Well, okay, done.
>> points at readable memory. Avoid a (likely nested) cras
On 03.07.2019 09:13, Juergen Gross wrote:
> On 02.07.19 17:01, Jan Beulich wrote:
> On 28.05.19 at 12:32, wrote:
>>> When running an idle vcpu in a non-idle scheduling unit use a specific
>>> guest idle loop not performing any tasklets, memory scrubbing and
>>> livepatching in order to avoid p
On 02.07.2019 16:41, Andrew Cooper wrote:
> On 27/06/2019 16:21, Jan Beulich wrote:
>> @@ -142,7 +187,21 @@ static void free_intremap_entry(unsigned
>> {
>> union irte_ptr entry = get_intremap_entry(seg, bdf, index);
>>
>> -ACCESS_ONCE(entry.ptr32->raw[0]) = 0;
>> +switch ( irte_
On 02.07.2019 17:08, Andrew Cooper wrote:
> On 27/06/2019 16:23, Jan Beulich wrote:
>> While for 32-bit IRTEs I think we can safely continue to assume that the
>> writes will translate to a single MOV, the use of CMPXCHG16B is more
>
> The CMPXCHG16B here is stale.
Indeed, as is the 32-bit IRTE p
flight 138705 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138705/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
build-amd64-prev 6 xen-bu
On 02.07.2019 18:38, Paul Durrant wrote:
> Alignment padding inserts a pseudo block header in front of the allocation,
> sets its size field to the pad size and then ORs in 1, which is equivalent
> to marking it as a free block, so that xfree() can distinguish it from a
> real block header.
>
> Th
EPT differs from NPT and shadow when translating page orders to levels
in the physmap page tables. EPT page tables level for order 0 pages is
0, while NPT and shadow instead use 1, ie: EPT page tables levels
starts at 0 while NPT and shadow starts at 1.
Fix the p2m_entry_modify call in atomic_writ
> -Original Message-
> From: Jan Beulich
> Sent: 03 July 2019 10:39
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Stefano
> Stabellini
> ; Konrad Rzeszutek Wilk ; Tim
> (Xen.org) ;
> Wei Liu
> Subject: Re: [PA
flight 138727 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138727/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 93ef224d63f9f04a0897d64981c619eb4816c0d3
baseline version:
xen cc07
On 02.07.2019 18:38, Paul Durrant wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -105,6 +105,13 @@ config DEBUG_TRACE
> either directly to the console or are printed to console in case of
> a system crash.
>
> +config POOL_POISON
May I suggest this to become XME
On 02.07.2019 18:38, Paul Durrant wrote:
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -380,18 +380,22 @@ void *xmem_pool_alloc(unsigned long size, struct
> xmem_pool *pool)
> int fl, sl;
> unsigned long tmp_size;
>
> +spin_lock(&pool->lock);
> if (
> -Original Message-
> From: Jan Beulich
> Sent: 03 July 2019 11:07
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ; Konrad
> Rzeszutek Wilk
> ; Tim (Xen.org) ; Wei Liu
> Subject: Re: [PA
> -Original Message-
> From: Jan Beulich
> Sent: 03 July 2019 10:57
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ; Konrad
> Rzeszutek Wilk
> ; Tim (Xen.org) ; Wei Liu
> Subject: Re: [PA
On 17/06/2019 09:13, Jan Beulich wrote:
> Despite -fno-omit-frame-pointer the compiler may omit the frame pointer,
> often for relatively simple leaf functions.
Actually, the problem is more widespread than this. For every function,
there is a non-zero quantity of time between the function starti
On 03.07.2019 11:43, Roger Pau Monne wrote:
> EPT differs from NPT and shadow when translating page orders to levels
> in the physmap page tables. EPT page tables level for order 0 pages is
> 0, while NPT and shadow instead use 1, ie: EPT page tables levels
> starts at 0 while NPT and shadow starts
On 03.07.2019 12:21, Andrew Cooper wrote:
> On 17/06/2019 09:13, Jan Beulich wrote:
>> Despite -fno-omit-frame-pointer the compiler may omit the frame pointer,
>> often for relatively simple leaf functions.
>
> Actually, the problem is more widespread than this. For every function,
> there is a n
>>> On 24.05.19 at 17:15, wrote:
> --- a/tools/tests/x86_emulator/Makefile
> +++ b/tools/tests/x86_emulator/Makefile
> @@ -149,7 +149,7 @@ $(addsuffix .h,$(TESTCASES)): %.h: %.c testcase.mk
> Makefile
> (echo 'static const unsigned int __attribute__((section(".test,
> \"ax\", @prog
A/D bit writes (on page walks) can be considered benign by an introspection
agent, so receiving vm_events for them is a pessimization. We try here to
optimize by fitering these events out.
Currently, we are fully emulating the instruction at RIP when the hardware sees
an EPT fault with npfec.kind !
On Wed, Jul 03, 2019 at 10:22:03AM +, Jan Beulich wrote:
> On 03.07.2019 11:43, Roger Pau Monne wrote:
> > EPT differs from NPT and shadow when translating page orders to levels
> > in the physmap page tables. EPT page tables level for order 0 pages is
> > 0, while NPT and shadow instead use 1,
On 03.07.2019 13:01, Roger Pau Monné wrote:
> On Wed, Jul 03, 2019 at 10:22:03AM +, Jan Beulich wrote:
>> On 03.07.2019 11:43, Roger Pau Monne wrote:
>>> EPT differs from NPT and shadow when translating page orders to levels
>>> in the physmap page tables. EPT page tables level for order 0 pag
>>> On 27.05.19 at 11:36, wrote:
On 12.04.19 at 13:41, wrote:
> On 11.04.19 at 21:06, wrote:
> > > On 11/04/2019 13:45, Jan Beulich wrote:
> > >> When disabling SMT at runtime, secondary threads should no longer be
> > >> candidates for bringing back up in response to _PUD ACPI events.
EPT differs from NPT and shadow when translating page orders to levels
in the physmap page tables. EPT page tables level for order 0 pages is
0, while NPT and shadow instead use 1, ie: EPT page tables levels
starts at 0 while NPT and shadow starts at 1.
Fix the p2m_entry_modify call in atomic_writ
On 01/02/2019 07:39, Jan Beulich wrote:
Basically, if you've got an updated dom0 kernel, you'll be fine even
with this default flipped. If you've forgotten/missed that, then you're
already wide open (in a lack of defence in depth way) and flipping the
default here will make thi
>>> On 02.05.19 at 13:35, wrote:
> Various CR3 and PCID related adjustments, first and foremost
> an almost full re-write of switch_cr3_cr4() (in patch 2).
>
> 1: x86: adjust cr3_pcid() return type
> 2: x86: limit the amount of TLB flushing in switch_cr3_cr4()
> 3: x86/mm: honor opt_pcid also for
On 03.07.2019 13:33, Roger Pau Monne wrote:
> EPT differs from NPT and shadow when translating page orders to levels
> in the physmap page tables. EPT page tables level for order 0 pages is
> 0, while NPT and shadow instead use 1, ie: EPT page tables levels
> starts at 0 while NPT and shadow starts
The write-discard property of the type can't be represented in IOMMU
page table entries. Make sure the respective checks / tracking can't
race, by utilizing the domain lock. The other sides of the sharing/
paging/log-dirty exclusion checks should subsequently perhaps also be
put under that lock the
On 03.07.2019 13:37, Andrew Cooper wrote:
> On 01/02/2019 07:39, Jan Beulich wrote:
> Basically, if you've got an updated dom0 kernel, you'll be fine even
> with this default flipped. If you've forgotten/missed that, then you're
> already wide open (in a lack of defence in depth way) a
When there's no XPTI-enabled PV domain at all, there's no need to issue
respective TLB flushes. Hardwire opt_xpti_* to false when !PV, and
record the creation of PV domains by bumping opt_xpti_* accordingly.
As to the sticky opt_xpti_domu vs increment/decrement of opt_xpti_hwdom,
this is done this
There are currently three more or less different checks:
- _get_page_type() adjusts the IOMMU mappings according to the new type
alone,
- arch_iommu_populate_page_table() wants just the type to be
PGT_writable_page,
- iommu_hwdom_init() additionally permits all other types with a type
refc
On 03/07/2019 07:30, Juergen Gross wrote:
> On 02.07.19 18:09, Andrew Cooper wrote:
>> On 28/05/2019 11:32, Juergen Gross wrote:
>>> Instead of dynamically decide whether the previous vcpu was using full
>>
>> "deciding"
>>
>>> or default GDT just add a percpu variable for that purpose. This at
>>
At this moment IOMMU pt sharing is disabled by commit [1].
This patch aims to clear the IOMMU hap share support as it will not be
used in the future. By doing this the IOMMU bits used in pte[52:58] can
be used in other ways.
[1] c2ba3db31ef2d9f1e40e7b6c16cf3be3d671d555
Suggested-by: George Dunla
The first patch is something I had meant to do forever since the introduction
of mwait-idle. The 2nd patch addresses a latent problem (becoming an active
one with patch 3) in C-state selection when actually entering an idle state.
The 3rd patch is my counterproposal to Brian's intended abuse (as I
While the MWAIT idle driver already takes it to mean an actual C state,
the ACPI idle driver so far used it as a list index. The list index,
however, is an implementation detail of Xen and affected by firmware
settings (i.e. not necessarily uniform for a particular system).
While touching this cod
For one on recent AMD CPUs entering C1 (if available at all) requires
use of MWAIT, while HLT (i.e. default_idle()) would put the processor
into as deep as CC6. And then even on other vendors' CPUs we should
avoid entering default_idle() when the intended state can be reached
by using the active id
At least for more recent CPUs, following what BKDG / PPR suggest for the
BIOS to surface via ACPI we can make ourselves independent of Dom0
uploading respective data.
Signed-off-by: Jan Beulich
---
v2: Handle Hygon Fam18. Set local_apic_timer_c2_ok (for Fam17 and Hygon
Fam18 only for now).
-
From: Ross Lagerwall
Signed-off-by: Ross Lagerwall
Make handling in do_pm_op() more homogeneous: Before interpreting
op->cpuid as such, handle all operations not acting on a particular
CPU. Also expose the setting via xenpm.
Signed-off-by: Jan Beulich
Acked-by: Wei Liu
---
v2: Adjust xenpm's
From: Ross Lagerwall
Allow limiting the max C-state sub-state by appending to the max_cstate
command-line parameter. E.g. max_cstate=1,0
The limit only applies to the highest legal C-state. For example:
max_cstate = 1, max_csubstate = 0 ==> C0, C1 okay, but not C1E
max_cstate = 1, max_csubsta
When allocating the guest memory for an HVM domain, libxc keeps the P2M
mapping for the entirety of the guest memory around for the time of the
launch as xc_dom_image->p2m_host. For guests that have a large memory
(3904 GiB), the p2m_host allocation takes more than 7.5 GiB of space, and
leaves xl s
>{
> @@ -1396,12 +1405,12 @@ int pmstat_reset_cx_stat(uint32_t cpuid)
>
>void cpuidle_disable_deep_cstate(void)
>{
> -if ( max_cstate > 1 )
> +if ( max_cstate > ACPI_STATE_C1 )
>{
>if ( local_apic_timer_c2_ok )
> -max_cstate = 2;
> +
On 01.07.2019 15:17, Paul Durrant wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -1450,7 +1450,7 @@ static int assign_device(struct domain *d, u16 seg, u8
> bus, u8 devfn, u32 flag)
>
> /* Prevent device assign if mem paging or mem sharing have bee
> -Original Message-
> From: Jan Beulich
> Sent: 03 July 2019 14:20
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Roger Pau Monne
> ; George Dunlap
> ; Tamas K Lengyel ; WeiLiu
>
> Subject: Re: [PATCH] passthrough/pci: properly qualify the
> mem_sharing_enab
On 01/07/2019 11:47, Jan Beulich wrote:
> On 01.07.2019 10:56, Andrew Cooper wrote:
>> On 01/07/2019 09:45, Petre Ovidiu PIRCALABU wrote:
>>> The problem lies with vfree because it creates a new list with the
>>> pages, unmaps the va pointer and then frees the pages. If I do these
>>> steps manuall
On 03.07.2019 15:22, Alexandru Stefan ISAILA wrote:
>> --- a/xen/arch/x86/cpu/mwait-idle.c
>> +++ b/xen/arch/x86/cpu/mwait-idle.c
>> @@ -731,7 +731,8 @@ static void mwait_idle(void)
>> } while (cx->type > max_cstate && --next_state);
>> if (!next_state)
>>
On 03.07.2019 15:25, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 03 July 2019 14:20
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Andrew Cooper ; Roger Pau Monne
>> ; George Dunlap
>> ; Tamas K Lengyel ; WeiLiu
>>
>> Subject: Re: [PATCH] passthr
On 03.07.2019 16:24, Jan Beulich wrote:
> On 03.07.2019 15:22, Alexandru Stefan ISAILA wrote:
>>> --- a/xen/arch/x86/cpu/mwait-idle.c
>>> +++ b/xen/arch/x86/cpu/mwait-idle.c
>>> @@ -731,7 +731,8 @@ static void mwait_idle(void)
>>> } while (cx->type > max_cstate && --next_state
On 03.07.2019 15:27, Andrew Cooper wrote:
> On 01/07/2019 11:47, Jan Beulich wrote:
>> On 01.07.2019 10:56, Andrew Cooper wrote:
>>> On 01/07/2019 09:45, Petre Ovidiu PIRCALABU wrote:
The problem lies with vfree because it creates a new list with the
pages, unmaps the va pointer and then
On 03.07.2019 15:35, Alexandru Stefan ISAILA wrote:
>
>
> On 03.07.2019 16:24, Jan Beulich wrote:
>> On 03.07.2019 15:22, Alexandru Stefan ISAILA wrote:
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -731,7 +731,8 @@ static void mwait_idle(void)
> -Original Message-
> From: Jan Beulich
> Sent: 03 July 2019 14:30
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Roger Pau
> Monne ; Tamas KLengyel ; WeiLiu
>
> Subject: Re: [PATCH] passthrough/pci: properly qualify the
> mem_sharing_enabl
On 03.07.19 01:51, Nadav Amit wrote:
To improve TLB shootdown performance, flush the remote and local TLBs
concurrently. Introduce flush_tlb_multi() that does so. Introduce
paravirtual versions of flush_tlb_multi() for KVM, Xen and hyper-v (Xen
and hyper-v are only compile-tested).
While the upd
flight 138710 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138710/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 133580
test-arm64-arm64-li
It is possible to receive multiple __pirq_guest_unbind calls for the same pirq
if the pirq has not yet been removed from the domain's pirq_tree. For a shared
pirq (nr_guests > 1), the first call zaps the current domain from the pirq's
guests[] list, but the action handler is never freed as there ar
On 7/2/19 10:42 AM, Chaitanya Kulkarni wrote:
+/* Helper function to read the bdev->bd_part->nr_sects */
+static inline sector_t bdev_nr_sects(struct block_device *bdev)
+{
+ return part_nr_sects_read(bdev->bd_part);
+}
Is the comment above bdev_nr_sects() really useful or should it be le
On 03.07.2019 16:46, Varad Gautam wrote:
> It is possible to receive multiple __pirq_guest_unbind calls for the same pirq
> if the pirq has not yet been removed from the domain's pirq_tree.
I'd appreciate if you would make clear under what conditions this can
happen, as I'm getting the impression
On 03.07.2019 15:06, Varad Gautam wrote:
> When allocating the guest memory for an HVM domain, libxc keeps the P2M
> mapping for the entirety of the guest memory around for the time of the
> launch as xc_dom_image->p2m_host. For guests that have a large memory
> (3904 GiB), the p2m_host allocation
> -Original Message-
> From: Jan Beulich
> Sent: 03 July 2019 12:36
> To: xen-devel@lists.xenproject.org
> Cc: George Dunlap ; Paul Durrant
> ; Andrew Cooper
> ; Wei Liu ; Roger Pau Monne
>
> Subject: [PATCH v2] x86/HVM: p2m_ram_ro is incompatible with device
> pass-through
>
> The wr
Hello,
I am trying to run xen and I have a problem:
https://pastebin.com/U0gch9us on line 190-193
So, it seems that Linux can't discover the irq domaing for crossbar
interrupt controller when running in dom0, but it has no problem when
running baremetal.
Here is the DT log with xen:
https://drive
On 17/05/2019 11:44, Jan Beulich wrote:
> The flag being set may prevent affinity changes, as these often imply
> assignment of a new vector. When there's no possible destination left
> for the IRQ, the clearing of the flag needs to happen right from
> fixup_irqs().
>
> Additionally _assign_irq_vec
On Wed, Jul 03, 2019 at 01:56:13PM +0800, Chao Gao wrote:
> To remove a device from a domain, a qmp command is sent to qemu. But it is
> handled by qemu asychronously. Even the qmp command is claimed to be done,
> the actual handling in qemu side may happen later.
> This behavior brings two questio
On 01.07.2019 13:13, Jan Beulich wrote:
> This goes on top of "x86emul: avoid speculative out of bounds
> accesses", or else there's a conflict in at least the "gather" patch
> here.
>
> 01: support AVX512{F,_VBMI2} compress/expand insns
> 02: support remaining misc AVX512{F,BW} insns
> 03: prepar
Also use this for AVX512_VBMI2 VPSH{L,R}D{,V}{D,Q,W} testing (only the
quad word right shifts get actually used; the assumption is that their
"left" counterparts as well as the double word and word forms then work
as well).
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v8: New.
--- a/t
On 17/05/2019 11:45, Jan Beulich wrote:
> The cleanup IPI may get sent immediately before a CPU gets removed from
> the online map. In such a case the IPI would get handled on the CPU
> being offlined no earlier than in the interrupts disabled window after
> fixup_irqs()' main loop. This is too lat
On 17/05/2019 11:46, Jan Beulich wrote:
> Don't log a stray trailing comma. Shorten a few fields.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Roger Pau Monné
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://
On Tue, Jul 02, 2019 at 02:07:27PM +, Zhang, Chen wrote:
> > On Mon, Jun 10, 2019 at 04:33:36PM +0800, Zhang Chen wrote:
> > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index
> > > f4fc96415d..6bb400efdf 100644
> > > --- a/tools/libxl/libxl_dm.c
> > > +++ b/tools/libxl/libxl_
> On Jul 3, 2019, at 7:04 AM, Juergen Gross wrote:
>
> On 03.07.19 01:51, Nadav Amit wrote:
>> To improve TLB shootdown performance, flush the remote and local TLBs
>> concurrently. Introduce flush_tlb_multi() that does so. Introduce
>> paravirtual versions of flush_tlb_multi() for KVM, Xen and h
On 03/07/2019 18:02, Nadav Amit wrote:
>> On Jul 3, 2019, at 7:04 AM, Juergen Gross wrote:
>>
>> On 03.07.19 01:51, Nadav Amit wrote:
>>> To improve TLB shootdown performance, flush the remote and local TLBs
>>> concurrently. Introduce flush_tlb_multi() that does so. Introduce
>>> paravirtual vers
On 17/05/2019 11:46, Jan Beulich wrote:
> @@ -2334,9 +2339,10 @@ static void dump_irqs(unsigned char key)
>
> spin_lock_irqsave(&desc->lock, flags);
>
> -printk(" IRQ:%4d aff:%*pb vec:%02x %-15s status=%03x ",
> - irq, nr_cpu_ids, cpumask_bits(desc->affinity),
On 17/05/2019 11:47, Jan Beulich wrote:
> Mixed meaning was implied so far by different pieces of code -
> disagreement was in particular about whether to expect offline CPUs'
> bits to possibly be set. Switch to a mostly consistent meaning
> (exception being high priority interrupts, which would p
> On Jul 3, 2019, at 10:43 AM, Andrew Cooper wrote:
>
> On 03/07/2019 18:02, Nadav Amit wrote:
>>> On Jul 3, 2019, at 7:04 AM, Juergen Gross wrote:
>>>
>>> On 03.07.19 01:51, Nadav Amit wrote:
To improve TLB shootdown performance, flush the remote and local TLBs
concurrently. Introduc
On 17/05/2019 11:47, Jan Beulich wrote:
> All of __{assign,bind,clear}_irq_vector() manipulate struct irq_desc
> fields, and hence ought to be called with the descriptor lock held in
> addition to vector_lock. This is currently the case for only
> set_desc_affinity() (in the common case) and destro
On 17/05/2019 11:48, Jan Beulich wrote:
> fixup_irqs() skips interrupts without action. Hence such interrupts can
> retain affinity to just offline CPUs. With "noirqbalance" in effect,
> pirq_guest_bind() so far would have left them alone, resulting in a non-
> working interrupt.
>
> Signed-off-by:
On 17/05/2019 11:49, Jan Beulich wrote:
> If any particular value was to be checked against, it would need to be
> IRQ_VECTOR_UNASSIGNED.
>
> Reported-by: Roger Pau Monné
>
> Be more strict though and use valid_irq_vector() instead.
>
> Take the opportunity and also convert local variables to unsi
On 17/05/2019 11:49, Jan Beulich wrote:
> Since the "Cannot set affinity ..." warning is a one time one, avoid
> triggering it already at boot time when parking secondary threads and
> the serial console uses a (still unconnected at that time) PCI IRQ.
>
> Signed-off-by: Jan Beulich
> Reviewed-by:
On 17/05/2019 11:50, Jan Beulich wrote:
> The subsequent cpumask_intersects() covers the "empty" case quite fine.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Roger Pau Monné
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproj
On 17/05/2019 11:51, Jan Beulich wrote:
> Its only caller already has the IRQ descriptor in its hands, so there's
> no need for the function to re-obtain it. As a result the leading p of
> its name is no longer appropriate and hence gets dropped.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Roger
On 17/05/2019 11:51, Jan Beulich wrote:
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -137,6 +137,13 @@ static void trace_irq_mask(uint32_t even
> trace_var(event, 1, sizeof(d), &d);
> }
>
> +static inline void trace_irq_mask(uint32_t event, int irq, int vector,
No inline. Ot
On 17/05/2019 11:52, Jan Beulich wrote:
> Use valid_irq_vector() rather than "> 0".
>
> Also replace an open-coded use of IRQ_VECTOR_UNASSIGNED.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproje
On 20/05/2019 15:22, Roger Pau Monné wrote:
> On Fri, May 17, 2019 at 04:52:54AM -0600, Jan Beulich wrote:
>> Use scratch_cpumask where possible, to avoid creating these possibly
>> large stack objects. We can't use it in _assign_irq_vector() and
>> set_desc_affinity(), as these get called in IRQ c
On 17/05/2019 11:53, Jan Beulich wrote:
> This is largely to drop a forward declaration. There's one functional
> change - clear_irq_vector() gets marked __init, as its only caller is
> check_timer(). Beyond this only a few stray blanks get removed.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew
flight 138712 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138712/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 137600
On 03/07/2019 14:06, Varad Gautam wrote:
> When allocating the guest memory for an HVM domain, libxc keeps the P2M
> mapping for the entirety of the guest memory around for the time of the
> launch as xc_dom_image->p2m_host. For guests that have a large memory
> (3904 GiB),
This is slightly awkwar
On 03/07/2019 11:34, Jan Beulich wrote:
> On 03.07.2019 12:21, Andrew Cooper wrote:
>> On 17/06/2019 09:13, Jan Beulich wrote:
>>> Despite -fno-omit-frame-pointer the compiler may omit the frame pointer,
>>> often for relatively simple leaf functions.
>> Actually, the problem is more widespread tha
flight 138715 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138715/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4286eb22f4aec33b90574b998a31f8bd34dd4f47
baseline version:
ovmf 21902410ad87aadd3a68e
flight 138714 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138714/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which are fail
On 7/3/19 8:03 AM, Bart Van Assche wrote:
+}
Is the comment above bdev_nr_sects() really useful or should it be left out?
Thanks,
Bart.
Sure, let me send V4 without the comment.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lis
Clean up unnecessory code after that operation.
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
---
Documentation/admin-guide/kernel-parameters.txt | 2 ++
arch/x86/xen/enlighten_hvm.c
.. as they are only called at early bootup stage. In fact, other
functions in x86_hyper_xen_hvm.init.* are all marked as __init.
Unexport xen_hvm_need_lapic as it's never used outside.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Boris Ostrovsky
Cc: Stefano Stabellini
Cc: Thom
PVH guest needs PV extentions to work, so "nopv" parameter should be
ignored for PVH but not for HVM guest.
If PVH guest boots up via the Xen-PVH boot entry, xen_pvh is set early,
we know it's PVH guest and ignore "nopv" parameter directly.
If PVH guest boots up via the normal boot entry same as
Hi,
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking, etc)
we want to disable PV extensions. We have xen_nopv for that purpose
but only f
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking)
we want to disable PV extensions. We have "xen_nopv" for that purpose
but only for XEN.
flight 138718 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138718/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt16 guest-start/debian.repeat fail REGR. vs. 138618
Tests which did not suc
flight 138717 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138717/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 138666
test-amd64-amd64-xl-qemut-win7-amd64
94 matches
Mail list logo
