[libvirt test] 157045: regressions - FAIL

flight 157045 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/157045/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-amd64-libvirt

Re: [PATCH 000/141] Fix fall-through warnings for Clang

On Thu, Nov 26, 2020 at 4:28 PM Geert Uytterhoeven wrote: > > Hi Miguel, > > On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda > wrote: > > On Wed, Nov 25, 2020 at 11:44 PM Edward Cree wrote: > > > To make the intent clear, you have to first be certain that you > > > understand the intent; otherwise

Re: [PATCH] xen/x86: Work around Clang code generation bug with asm parameters

On 12.11.2020 09:14, Jan Beulich wrote: > On 11.11.2020 21:01, Andrew Cooper wrote: >> On 11/11/2020 15:11, Jan Beulich wrote: >>> On 11.11.2020 13:45, Andrew Cooper wrote: Clang 9 and later don't handle the clobber of %r10 correctly in _hypercall64_4(). See https://bugs.llvm.org/show_bu

[PATCH] x86/msr: don't inject #GP when trying to read FEATURE_CONTROL

Windows 10 will triple fault if #GP is injected when attempting to read the FEATURE_CONTROL MSR on Intel or compatible hardware. Fix this by injecting a #GP only when the vendor doesn't support the MSR, even if there are no features to expose. Fixes: 39ab598c50a2 ('x86/pv: allow reading FEATURE_CO

Re: [PATCH] x86/msr: don't inject #GP when trying to read FEATURE_CONTROL

On 27.11.2020 11:46, Roger Pau Monne wrote: > Windows 10 will triple fault if #GP is injected when attempting to > read the FEATURE_CONTROL MSR on Intel or compatible hardware. Fix this > by injecting a #GP only when the vendor doesn't support the MSR, even > if there are no features to expose. >

Re: NetBSD dom0 PVH: hardware interrupts stalls

On Thu, Nov 26, 2020 at 06:20:34PM +0100, Manuel Bouyer wrote: > On Thu, Nov 26, 2020 at 04:09:37PM +0100, Roger Pau Monné wrote: > > > > > > Oh, that's actually very useful. The interrupt is being constantly > > > injected from the hardware and received by Xen, it's just not then > > > injected i

Re: NetBSD dom0 PVH: hardware interrupts stalls

On 27.11.2020 11:59, Roger Pau Monné wrote: > On Thu, Nov 26, 2020 at 06:20:34PM +0100, Manuel Bouyer wrote: >> On Thu, Nov 26, 2020 at 04:09:37PM +0100, Roger Pau Monné wrote: Oh, that's actually very useful. The interrupt is being constantly injected from the hardware and received

Re: NetBSD dom0 PVH: hardware interrupts stalls

On Fri, Nov 27, 2020 at 11:59:48AM +0100, Roger Pau Monné wrote: > > > > I had to restart from a clean source tree to apply this patch, so to make > > sure we're in sync I attached the diff from my sources > > I'm quite confused about why your trace don't even get into > hvm_do_IRQ_dpci, so I've

Re: NetBSD dom0 PVH: hardware interrupts stalls

On 27.11.2020 12:19, Manuel Bouyer wrote: > On Fri, Nov 27, 2020 at 11:59:48AM +0100, Roger Pau Monné wrote: >>> >>> I had to restart from a clean source tree to apply this patch, so to make >>> sure we're in sync I attached the diff from my sources >> >> I'm quite confused about why your trace don

Re: NetBSD dom0 PVH: hardware interrupts stalls

On 27.11.2020 11:59, Roger Pau Monné wrote: > --- a/xen/arch/x86/hvm/irq.c > +++ b/xen/arch/x86/hvm/irq.c > @@ -187,6 +187,10 @@ void hvm_gsi_assert(struct domain *d, unsigned int gsi) > * to know if the GSI is pending or not. > */ > spin_lock(&d->arch.hvm.irq_lock); > +if ( gs

Re: [PATCH v2 03/12] x86/pv: switch SWAPGS to ALTERNATIVE

On Fri, Nov 20, 2020 at 12:46:21PM +0100, Juergen Gross wrote: > SWAPGS is used only for interrupts coming from user mode or for > returning to user mode. So there is no reason to use the PARAVIRT > framework, as it can easily be replaced by an ALTERNATIVE depending > on X86_FEATURE_XENPV. > > The

Re: [PATCH v8 1/3] xen/events: modify struct evtchn layout

On 25.11.2020 11:51, Juergen Gross wrote: > In order to avoid latent races when updating an event channel put > xen_consumer and pending fields in different bytes. This is no problem > right now, but especially the pending indicator isn't used only when > initializing an event channel (unlike xen_c

[ANNOUNCE] Call for agenda items for December 2020 Community Call @ 16:00 UTC

Hi all, The proposed agenda is in https://cryptpad.fr/pad/#/2/pad/edit/OPN55rXaOncupuWuHxtddzWJ/ and you can edit to add items. Alternatively, you can reply to this mail directly. Agenda items appreciated a few days before the call: please put your name besides items if you edit the document

Re: [PATCH v8 1/3] xen/events: modify struct evtchn layout

Hi Jan, On 27/11/2020 11:42, Jan Beulich wrote: On 25.11.2020 11:51, Juergen Gross wrote: In order to avoid latent races when updating an event channel put xen_consumer and pending fields in different bytes. This is no problem right now, but especially the pending indicator isn't used only when

Re: [PATCH v2 4/6] xen: Delete xen_available() function

On Wed, 25 Nov 2020 15:56:34 -0500 Eduardo Habkost wrote: > The function can be replaced with accel_available("xen"). > > Signed-off-by: Eduardo Habkost > --- > Cc: Paolo Bonzini > Cc: qemu-de...@nongnu.org > Cc: Stefano Stabellini > Cc: Anthony Perard > Cc: Paul Durrant > Cc: xen-devel@lis

Re: [PATCH v8 1/3] xen/events: modify struct evtchn layout

On 27.11.2020 12:57, Julien Grall wrote: > On 27/11/2020 11:42, Jan Beulich wrote: >> I have to admit though that I'm not fully happy with the uses of >> "unsigned char" and "unsigned short". Yes, I did ask for this >> change (based on ./CODING_STYLE), but I did also hint towards the >> use of bitf

Re: NetBSD dom0 PVH: hardware interrupts stalls

On Fri, Nov 27, 2020 at 12:21:23PM +0100, Jan Beulich wrote: > On 27.11.2020 12:19, Manuel Bouyer wrote: > > On Fri, Nov 27, 2020 at 11:59:48AM +0100, Roger Pau Monné wrote: > >>> > >>> I had to restart from a clean source tree to apply this patch, so to make > >>> sure we're in sync I attached the

Re: [PATCH v8 2/3] xen/events: rework fifo queue locking

On 25.11.2020 11:51, Juergen Gross wrote: > Two cpus entering evtchn_fifo_set_pending() for the same event channel > can race in case the first one gets interrupted after setting > EVTCHN_FIFO_PENDING and when the other one manages to set > EVTCHN_FIFO_LINKED before the first one is testing that bi

Re: NetBSD dom0 PVH: hardware interrupts stalls

On Fri, Nov 27, 2020 at 12:29:35PM +0100, Jan Beulich wrote: > On 27.11.2020 11:59, Roger Pau Monné wrote: > > --- a/xen/arch/x86/hvm/irq.c > > +++ b/xen/arch/x86/hvm/irq.c > > @@ -187,6 +187,10 @@ void hvm_gsi_assert(struct domain *d, unsigned int gsi) > > * to know if the GSI is pending or

Re: NetBSD dom0 PVH: hardware interrupts stalls

On 27.11.2020 14:10, Manuel Bouyer wrote: > On Fri, Nov 27, 2020 at 12:21:23PM +0100, Jan Beulich wrote: >> On 27.11.2020 12:19, Manuel Bouyer wrote: >>> On Fri, Nov 27, 2020 at 11:59:48AM +0100, Roger Pau Monné wrote: > > I had to restart from a clean source tree to apply this patch, so to

[xen-unstable test] 157044: tolerable FAIL

flight 157044 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/157044/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 14 guest-start/redhat.repeat fail pass in 157028 test-amd64-amd64-examine

Re: NetBSD dom0 PVH: hardware interrupts stalls

On Fri, Nov 27, 2020 at 02:14:55PM +0100, Jan Beulich wrote: > Ah yes. In your respective mail the link said 9 though instead of 10. Ops, sorry. I forgot to update the link I guess ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --

Re: NetBSD dom0 PVH: hardware interrupts stalls

On 27.11.2020 14:13, Manuel Bouyer wrote: > On Fri, Nov 27, 2020 at 12:29:35PM +0100, Jan Beulich wrote: >> On 27.11.2020 11:59, Roger Pau Monné wrote: >>> --- a/xen/arch/x86/hvm/irq.c >>> +++ b/xen/arch/x86/hvm/irq.c >>> @@ -187,6 +187,10 @@ void hvm_gsi_assert(struct domain *d, unsigned int gsi)

Re: [PATCH v8 3/3] xen/events: do some cleanups in evtchn_fifo_set_pending()

On 25.11.2020 11:51, Juergen Gross wrote: > --- a/xen/common/event_fifo.c > +++ b/xen/common/event_fifo.c > @@ -175,6 +175,18 @@ static void evtchn_fifo_set_pending(struct vcpu *v, > struct evtchn *evtchn) > return; > } > > +/* > + * Control block not mapped. The guest mus

Re: NetBSD dom0 PVH: hardware interrupts stalls

On Fri, Nov 27, 2020 at 02:18:54PM +0100, Jan Beulich wrote: > On 27.11.2020 14:13, Manuel Bouyer wrote: > > On Fri, Nov 27, 2020 at 12:29:35PM +0100, Jan Beulich wrote: > >> On 27.11.2020 11:59, Roger Pau Monné wrote: > >>> --- a/xen/arch/x86/hvm/irq.c > >>> +++ b/xen/arch/x86/hvm/irq.c > >>> @@ -

Re: [PATCH v8 2/3] xen/events: rework fifo queue locking

On 27.11.20 14:11, Jan Beulich wrote: On 25.11.2020 11:51, Juergen Gross wrote: Two cpus entering evtchn_fifo_set_pending() for the same event channel can race in case the first one gets interrupted after setting EVTCHN_FIFO_PENDING and when the other one manages to set EVTCHN_FIFO_LINKED before

Re: [PATCH v4 1/3] xen/pci: Move x86 specific code to x86 directory.

On 25.11.2020 19:16, Rahul Singh wrote: > --- a/xen/drivers/passthrough/pci.c > +++ b/xen/drivers/passthrough/pci.c > @@ -14,9 +14,6 @@ > * this program; If not, see . > */ > > -#include > -#include > -#include > #include > #include > #include At least

Re: NetBSD dom0 PVH: hardware interrupts stalls

On 27.11.2020 14:31, Manuel Bouyer wrote: > On Fri, Nov 27, 2020 at 02:18:54PM +0100, Jan Beulich wrote: >> On 27.11.2020 14:13, Manuel Bouyer wrote: >>> On Fri, Nov 27, 2020 at 12:29:35PM +0100, Jan Beulich wrote: On 27.11.2020 11:59, Roger Pau Monné wrote: > --- a/xen/arch/x86/hvm/irq.c

Re: [PATCH v4 2/3] xen/pci: solve compilation error on ARM with HAS_PCI enabled.

On 26.11.2020 10:05, Bertrand Marquis wrote: > > >> On 25 Nov 2020, at 18:16, Rahul Singh wrote: >> >> If mem-sharing, mem-paging, or log-dirty functionality is not enabled >> for architecture when HAS_PCI is enabled, the compiler will throw an >> error. >> >> Move code to x86 specific file to f

Re: NetBSD dom0 PVH: hardware interrupts stalls

On 27.11.20 14:40, Jan Beulich wrote: On 27.11.2020 14:31, Manuel Bouyer wrote: On Fri, Nov 27, 2020 at 02:18:54PM +0100, Jan Beulich wrote: On 27.11.2020 14:13, Manuel Bouyer wrote: On Fri, Nov 27, 2020 at 12:29:35PM +0100, Jan Beulich wrote: On 27.11.2020 11:59, Roger Pau Monné wrote: ---

Re: [PATCH v8 3/3] xen/events: do some cleanups in evtchn_fifo_set_pending()

On 27.11.20 14:27, Jan Beulich wrote: On 25.11.2020 11:51, Juergen Gross wrote: --- a/xen/common/event_fifo.c +++ b/xen/common/event_fifo.c @@ -175,6 +175,18 @@ static void evtchn_fifo_set_pending(struct vcpu *v, struct evtchn *evtchn) return; } +/* + * Control block

Re: [PATCH v4 3/3] ns16550: Gate all PCI code with CONFIG_X86

On 25.11.2020 19:16, Rahul Singh wrote: > --- a/xen/drivers/char/ns16550.c > +++ b/xen/drivers/char/ns16550.c > @@ -16,7 +16,7 @@ > #include > #include > #include > -#ifdef CONFIG_HAS_PCI > +#if defined(CONFIG_X86) && defined(CONFIG_HAS_PCI) > #include > #include > #include > @@ -51,7 +

Re: [PATCH v8 2/3] xen/events: rework fifo queue locking

Hi Juergen, On 25/11/2020 10:51, Juergen Gross wrote: -static struct evtchn_fifo_queue *lock_old_queue(const struct domain *d, -struct evtchn *evtchn, -unsigned long *flags) -{ -struct vcpu *v; -

Re: NetBSD dom0 PVH: hardware interrupts stalls

On Fri, Nov 27, 2020 at 02:40:22PM +0100, Jan Beulich wrote: > On 27.11.2020 14:31, Manuel Bouyer wrote: > > On Fri, Nov 27, 2020 at 02:18:54PM +0100, Jan Beulich wrote: > >> On 27.11.2020 14:13, Manuel Bouyer wrote: > >>> On Fri, Nov 27, 2020 at 12:29:35PM +0100, Jan Beulich wrote: > On 27.11

Re: [PATCH v8 2/3] xen/events: rework fifo queue locking

On 27.11.2020 14:58, Julien Grall wrote: > On 25/11/2020 10:51, Juergen Gross wrote: >> +/* If we didn't get the lock bail out. */ >> +if ( try == 4 ) >> +{ >> +gprintk(XENLOG_WARNING, >> +"dom%d port %d lost event (too many queue changes)\n", >> +

Re: [PATCH v8 2/3] xen/events: rework fifo queue locking

On 27.11.20 14:58, Julien Grall wrote: Hi Juergen, On 25/11/2020 10:51, Juergen Gross wrote: -static struct evtchn_fifo_queue *lock_old_queue(const struct domain *d, -    struct evtchn *evtchn, -    unsigned

Re: [PATCH v8 2/3] xen/events: rework fifo queue locking

Hi Juergen, On 27/11/2020 14:05, Jürgen Groß wrote: On 27.11.20 14:58, Julien Grall wrote: Hi Juergen, On 25/11/2020 10:51, Juergen Gross wrote: -static struct evtchn_fifo_queue *lock_old_queue(const struct domain *d, -    struct evtchn *evtchn, -  

Re: [PATCH v8 2/3] xen/events: rework fifo queue locking

On 27.11.20 15:11, Julien Grall wrote: Hi Juergen, On 27/11/2020 14:05, Jürgen Groß wrote: On 27.11.20 14:58, Julien Grall wrote: Hi Juergen, On 25/11/2020 10:51, Juergen Gross wrote: -static struct evtchn_fifo_queue *lock_old_queue(const struct domain *d, - 

Re: [PATCH v4 3/3] ns16550: Gate all PCI code with CONFIG_X86

Hi Jan, > On 27 Nov 2020, at 13:58, Jan Beulich wrote: > > On 25.11.2020 19:16, Rahul Singh wrote: >> --- a/xen/drivers/char/ns16550.c >> +++ b/xen/drivers/char/ns16550.c >> @@ -16,7 +16,7 @@ >> #include >> #include >> #include >> -#ifdef CONFIG_HAS_PCI >> +#if defined(CONFIG_X86) && defined(

Re: [PATCH v8 3/3] xen/events: do some cleanups in evtchn_fifo_set_pending()

On 25/11/2020 10:51, Juergen Gross wrote: evtchn_fifo_set_pending() can be simplified a little bit. The commit message is quite light... For posterity, it would be good to explain why the simplication can be done. In particular, there is a chance in behavior after this patch. Suggested-

Re: [PATCH-for-6.0 v4 15/17] gitlab-ci: Add test for Xen (on CentOS 7)

On Thu, Nov 26, 2020 at 12:45:59PM -0500, Eduardo Habkost wrote: > On Thu, Nov 26, 2020 at 05:38:24PM +, Anthony PERARD wrote: > > Is `make check` going to do something useful with the Xen support? Or is > > it going to need more work in order to test the Xen support of QEMU? > > (Like starting

Re: [PATCH v4 3/3] ns16550: Gate all PCI code with CONFIG_X86

Hello Jan, > On 27 Nov 2020, at 1:58 pm, Jan Beulich wrote: > > On 25.11.2020 19:16, Rahul Singh wrote: >> --- a/xen/drivers/char/ns16550.c >> +++ b/xen/drivers/char/ns16550.c >> @@ -16,7 +16,7 @@ >> #include >> #include >> #include >> -#ifdef CONFIG_HAS_PCI >> +#if defined(CONFIG_X86) && def

Re: [PATCH v8 2/3] xen/events: rework fifo queue locking

On 27/11/2020 14:14, Jürgen Groß wrote: On 27.11.20 15:11, Julien Grall wrote: Hi Juergen, On 27/11/2020 14:05, Jürgen Groß wrote: On 27.11.20 14:58, Julien Grall wrote: Hi Juergen, On 25/11/2020 10:51, Juergen Gross wrote: -static struct evtchn_fifo_queue *lock_old_queue(const struct do

Re: [PATCH v8 3/3] xen/events: do some cleanups in evtchn_fifo_set_pending()

On 27.11.20 15:23, Julien Grall wrote: On 25/11/2020 10:51, Juergen Gross wrote: evtchn_fifo_set_pending() can be simplified a little bit. The commit message is quite light... For posterity, it would be good to explain why the simplication can be done. In particular, there is a chance in b

Re: [PATCH v10 1/7] remove remaining uses of iommu_legacy_map/unmap

On 20.11.2020 14:24, Paul Durrant wrote: > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -2489,10 +2489,16 @@ static int cleanup_page_mappings(struct page_info > *page) > > if ( d && unlikely(need_iommu_pt_sync(d)) && is_pv_domain(d) ) > { > -int rc2 = iomm

Re: [PATCH v8 3/3] xen/events: do some cleanups in evtchn_fifo_set_pending()

On 27.11.2020 15:39, Jürgen Groß wrote: > On 27.11.20 15:23, Julien Grall wrote: >> On 25/11/2020 10:51, Juergen Gross wrote: >>> --- a/xen/common/event_fifo.c >>> +++ b/xen/common/event_fifo.c >>> @@ -175,6 +175,18 @@ static void evtchn_fifo_set_pending(struct vcpu >>> *v, struct evtchn *evtchn)

Re: [PATCH v8 3/3] xen/events: do some cleanups in evtchn_fifo_set_pending()

On 27/11/2020 14:39, Jürgen Groß wrote: On 27.11.20 15:23, Julien Grall wrote: On 25/11/2020 10:51, Juergen Gross wrote: evtchn_fifo_set_pending() can be simplified a little bit. The commit message is quite light... For posterity, it would be good to explain why the simplication can be

Re: [PATCH v2 4/6] xen: Delete xen_available() function

On Wed, Nov 25, 2020 at 03:56:34PM -0500, Eduardo Habkost wrote: > The function can be replaced with accel_available("xen"). > > Signed-off-by: Eduardo Habkost Acked-by: Anthony PERARD Thanks, -- Anthony PERARD

Re: [PATCH v10 5/7] vtd: use a bit field for root_entry

On 20.11.2020 14:24, Paul Durrant wrote: > @@ -85,25 +85,28 @@ static bool device_in_domain(const struct vtd_iommu > *iommu, > return false; > } > > -root_entry = map_vtd_domain_page(iommu->root_maddr); > -if ( !root_present(root_entry[pdev->bus]) ) > +root_entries = (s

Re: [PATCH v8 3/3] xen/events: do some cleanups in evtchn_fifo_set_pending()

On 27/11/2020 14:48, Jan Beulich wrote: On 27.11.2020 15:39, Jürgen Groß wrote: On 27.11.20 15:23, Julien Grall wrote: On 25/11/2020 10:51, Juergen Gross wrote: --- a/xen/common/event_fifo.c +++ b/xen/common/event_fifo.c @@ -175,6 +175,18 @@ static void evtchn_fifo_set_pending(struct vcpu *

Re: [PATCH v10 6/7] vtd: use a bit field for context_entry

On 20.11.2020 14:24, Paul Durrant wrote: > @@ -121,21 +119,22 @@ static int context_set_domain_id(struct context_entry > *context, > } > > set_bit(i, iommu->domid_bitmap); > -context->hi |= (i & ((1 << DID_FIELD_WIDTH) - 1)) << DID_HIGH_OFFSET; > +context->did = i; > + > r

Re: [PATCH v8 3/3] xen/events: do some cleanups in evtchn_fifo_set_pending()

On 27.11.2020 16:17, Julien Grall wrote: > > > On 27/11/2020 14:48, Jan Beulich wrote: >> On 27.11.2020 15:39, Jürgen Groß wrote: >>> On 27.11.20 15:23, Julien Grall wrote: On 25/11/2020 10:51, Juergen Gross wrote: > --- a/xen/common/event_fifo.c > +++ b/xen/common/event_fifo.c >

Re: [PATCH v10 7/7] vtd: use a bit field for dma_pte

On 20.11.2020 14:24, Paul Durrant wrote: > @@ -709,20 +709,23 @@ static void dma_pte_clear_one(struct domain *domain, > uint64_t addr, > page = (struct dma_pte *)map_vtd_domain_page(pg_maddr); > pte = page + address_level_offset(addr, 1); > > -if ( !dma_pte_present(*pte) ) > +i

[PATCH] xen: remove trailing semicolon in macro definition

From: Tom Rix The macro use will already have a semicolon. Signed-off-by: Tom Rix --- arch/x86/include/asm/xen/page.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h index 5941e18edd5a..1a162e559753 100644 --

Re: [PATCH v10 0/7] IOMMU cleanup

On 20.11.2020 14:24, Paul Durrant wrote: > From: Paul Durrant > > This is the remainder of the cleanup series deferred until XSA-346 and > XSA-347 were publicly disclosed. > > Paul Durrant (7): > remove remaining uses of iommu_legacy_map/unmap > common/grant_table: batch flush I/O TLB > io

RE: [PATCH v10 0/7] IOMMU cleanup

> -Original Message- > From: Jan Beulich > Sent: 27 November 2020 16:22 > To: Paul Durrant > Cc: Durrant, Paul ; Andrew Cooper > ; George Dunlap > ; Ian Jackson ; Grall, > Julien > ; Jun Nakajima ; Kevin Tian > ; Roger > Pau Monné ; Stefano Stabellini > ; Wei Liu ; > xen-devel@lists.x

[PATCH v4] IOMMU: make DMA containment of quarantined devices optional

Containing still in flight DMA was introduced to work around certain devices / systems hanging hard upon hitting a "not-present" IOMMU fault. Passing through (such) devices (on such systems) is inherently insecure (as guests could easily arrange for IOMMU faults of any kind to occur). Defaulting to

[PATCH 0/2] x86: is_pv*domain() adjustments

1: correct is_pv_domain() when !CONFIG_PV 2: use is_pv_64bit_domain() to avoid double evaluate_nospec() Jan

[PATCH 1/2] x86: correct is_pv_domain() when !CONFIG_PV

On x86, idle and other system domains are implicitly PV. While I couldn't spot any cases where this is actively a problem, some cases required quite close inspection to be certain there couldn't e.g. be some ASSERT_UNREACHABLE() that would trigger in this case. Let's be on the safe side and make su

[PATCH 2/2] x86: use is_pv_64bit_domain() to avoid double evaluate_nospec()

Signed-off-by: Jan Beulich --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -1085,7 +1085,7 @@ int arch_set_info_guest( * update_cr3(), sh_update_cr3(), sh_walk_guest_tables(), and * shadow_one_bit_disable() for why that is. */ - !is_hvm_domain(d

[qemu-mainline test] 157048: regressions - FAIL

flight 157048 qemu-mainline real [real] flight 157054 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/157048/ http://logs.test-lab.xenproject.org/osstest/logs/157054/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

Re: [PATCH 0/8] Rid W=1 warnings in Net

On Thu, 26 Nov 2020 13:38:45 + Lee Jones wrote: > Resending the stragglers. > > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. This set doesn't apply to net-next, please rebase.

[ovmf test] 157055: all pass - PUSHED

flight 157055 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/157055/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 73b604bb1e13ff915c523180979f7b4db34b6d1b baseline version: ovmf 872f953262d68a11da7bc

[linux-linus test] 157049: regressions - FAIL

flight 157049 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/157049/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-

Re: [PATCH v4 0/3] xen/arm: Make PCI passthrough code non-x86 specific

On 25/11/2020 18:16, Rahul Singh wrote: > This patch series is v4 of preparatory work to make PCI passthrough code > non-x86 specific. > > Rahul Singh (3): > xen/pci: Move x86 specific code to x86 directory. > xen/pci: solve compilation error on ARM with HAS_PCI enabled. > ns16550: Gate all P

Re: [PATCH 0/7] xen/arm: Emulate ID registers

On 26/11/2020 15:51, Bertrand Marquis wrote: > The goal of this serie is to emulate coprocessor ID registers so that > Xen only publish to guest features that are supported by Xen and can > actually be used by guests. > One practical example where this is required are SVE support which is > forbidd

Re: [PATCH v4 0/3] xen/arm: Make PCI passthrough code non-x86 specific

On 27/11/2020 20:04, Andrew Cooper wrote: > On 25/11/2020 18:16, Rahul Singh wrote: >> This patch series is v4 of preparatory work to make PCI passthrough code >> non-x86 specific. >> >> Rahul Singh (3): >> xen/pci: Move x86 specific code to x86 directory. >> xen/pci: solve compilation error on

[xen-unstable-smoke test] 157058: tolerable all pass - PUSHED

flight 157058 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/157058/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

Re: NetBSD dom0 PVH: hardware interrupts stalls

On Fri, Nov 27, 2020 at 02:59:29PM +0100, Manuel Bouyer wrote: > On Fri, Nov 27, 2020 at 02:40:22PM +0100, Jan Beulich wrote: > > On 27.11.2020 14:31, Manuel Bouyer wrote: > > > On Fri, Nov 27, 2020 at 02:18:54PM +0100, Jan Beulich wrote: > > >> On 27.11.2020 14:13, Manuel Bouyer wrote: > > >>> On

Re: NetBSD dom0 PVH: hardware interrupts stalls

On Fri, Nov 27, 2020 at 09:22:11PM +0100, Roger Pau Monné wrote: > > > > But I can confirm that now, entering ^A^A^A gets interrupt going in again > > I think there are some weird things with dpci interrupts that I'm > trying to understand. I have a patch now that will panic when the > buffer is

[ovmf test] 157060: all pass - PUSHED

flight 157060 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/157060/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf f69a2b9a42029bcbcf88d074425ebe63495b0a08 baseline version: ovmf 73b604bb1e13ff915c523

Re: Xen on RP4

On Wed, Nov 25, 2020 at 10:57:31AM -0800, Stefano Stabellini wrote: > On Tue, 24 Nov 2020, Elliott Mitchell wrote: > > I've frankly got no idea how to ensure the correct device-tree is passed > > to Xen. Is GRUB's `devicetree` command correct when loading Xen? Is a > > device-tree matched to the

[qemu-mainline test] 157056: regressions - FAIL

flight 157056 qemu-mainline real [real] flight 157066 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/157056/ http://logs.test-lab.xenproject.org/osstest/logs/157066/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

[linux-linus test] 157062: regressions - FAIL

flight 157062 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/157062/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-

[libvirt test] 157067: regressions - FAIL

flight 157067 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/157067/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-amd64-libvirt

Re: Xen on RP4

On Wed, Nov 25, 2020 at 7:36 PM Elliott Mitchell wrote: > > On Wed, Nov 25, 2020 at 10:57:31AM -0800, Stefano Stabellini wrote: > > On Tue, 24 Nov 2020, Elliott Mitchell wrote: > > > My testing section for Xen is: > > > xen_hypervisor /boot/xen-4.14-arm64.efi > > > xen_module /boot/vmlinuz