[Xen-devel] [qemu-mainline test] 119386: tolerable FAIL - PUSHED

flight 119386 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/119386/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 119036 test-armhf-armhf-libvirt-xsm 14

Re: [Xen-devel] [PATCH v2] x86/nmi: start NMI watchdog on CPU0 after SMP bootstrap

On Fri, 16 Feb 2018 17:46:48 + Igor Druzhinin wrote: >We're noticing a reproducible system boot hang on certain >post-Skylake platforms where the BIOS is configured in >legacy boot mode with x2APIC disabled. The system stalls >immediately after writing the first

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemut-win7-amd64

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemut-win7-amd64 testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

Re: [Xen-devel] [PATCH 2/4] xen/arm: read ACTLR on the pcpu where the vcpu will run

On Fri, 16 Feb 2018, Julien Grall wrote: > Hi Stefano, > > On 15/02/18 23:16, Stefano Stabellini wrote: > > On big.LITTLE systems not all cores have the same ACTLR. Instead of > > reading ACTLR and setting v->arch.actlr in vcpu_initialise, which is run > > always on pcpu 0, do it later on the

[Xen-devel] [xen-unstable test] 119358: regressions - FAIL

flight 119358 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/119358/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118698 Regressions which

Re: [Xen-devel] [PATCH 4/4] xen/arm: update the docs about heterogeneous computing

On Fri, 16 Feb 2018, Julien Grall wrote: > On 16/02/2018 21:15, Stefano Stabellini wrote: > > On Fri, 16 Feb 2018, Julien Grall wrote: > > > On 16/02/2018 20:50, Stefano Stabellini wrote: > > > > On Fri, 16 Feb 2018, Julien Grall wrote: > > > > > Hi Stefano, > > > > > > > > > > On 15/02/18 23:17,

[Xen-devel] [xen-unstable-smoke test] 119436: tolerable all pass - PUSHED

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

[Xen-devel] [xtf test] 119433: tolerable all pass - PUSHED

flight 119433 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/119433/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-3 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-4 52

Re: [Xen-devel] [PATCH 0/4] unsafe big.LITTLE support

On Fri, 16 Feb 2018, Julien Grall wrote: > On 15/02/18 23:16, Stefano Stabellini wrote: > > Hi all, > > Hi Stefano, > > > This series changes the initialization of two virtual registers to make > > sure they match the value of the underlying physical cpu. > > > > It also disables cpus different

Re: [Xen-devel] [PATCH 4/4] xen/arm: update the docs about heterogeneous computing

On 16/02/2018 21:15, Stefano Stabellini wrote: On Fri, 16 Feb 2018, Julien Grall wrote: On 16/02/2018 20:50, Stefano Stabellini wrote: On Fri, 16 Feb 2018, Julien Grall wrote: Hi Stefano, On 15/02/18 23:17, Stefano Stabellini wrote: Update the documentation of the hmp-unsafe option to

Re: [Xen-devel] [PATCH 3/4] xen/arm: set vpidr on the pcpu where the vcpu will run

Hi Stefano, On 16/02/2018 21:34, Stefano Stabellini wrote: On Fri, 16 Feb 2018, Julien Grall wrote: Hi Stefano, On 16/02/2018 20:59, Stefano Stabellini wrote: On Fri, 16 Feb 2018, Julien Grall wrote: On 16/02/2018 20:31, Stefano Stabellini wrote: On Fri, 16 Feb 2018, Julien Grall wrote:

Re: [Xen-devel] PV guest with PCI passthrough crash on Xen 4.8.3 inside KVM when booted through OVMF

On Feb 16, 2018, at 14:02, Andrew Cooper wrote: > > IMO, PCI Passthrough is a trainwreck, and it is a miracle it functions > at all. Would that statement apply to other hypervisors like KVM, VMware ESX or Hyper-V, i.e. are the deficiencies in PCI devices/firmware,

Re: [Xen-devel] [PATCH 3/4] xen/arm: set vpidr on the pcpu where the vcpu will run

On Fri, 16 Feb 2018, Julien Grall wrote: > Hi Stefano, > > On 16/02/2018 20:59, Stefano Stabellini wrote: > > On Fri, 16 Feb 2018, Julien Grall wrote: > > > On 16/02/2018 20:31, Stefano Stabellini wrote: > > > > On Fri, 16 Feb 2018, Julien Grall wrote: > > > > > Hi Stefano, > > > > > > > > > >

Re: [Xen-devel] [PATCH 4/4] xen/arm: update the docs about heterogeneous computing

On Fri, 16 Feb 2018, Julien Grall wrote: > On 16/02/2018 20:50, Stefano Stabellini wrote: > > On Fri, 16 Feb 2018, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 15/02/18 23:17, Stefano Stabellini wrote: > > > > Update the documentation of the hmp-unsafe option to explain how to use > > > >

Re: [Xen-devel] [PATCH 3/4] xen/arm: set vpidr on the pcpu where the vcpu will run

Hi Stefano, On 16/02/2018 20:59, Stefano Stabellini wrote: On Fri, 16 Feb 2018, Julien Grall wrote: On 16/02/2018 20:31, Stefano Stabellini wrote: On Fri, 16 Feb 2018, Julien Grall wrote: Hi Stefano, On 15/02/18 23:16, Stefano Stabellini wrote: On big.LITTLE systems not all cores have the

Re: [Xen-devel] [PATCH 4/4] xen/arm: update the docs about heterogeneous computing

On 16/02/2018 20:50, Stefano Stabellini wrote: On Fri, 16 Feb 2018, Julien Grall wrote: Hi Stefano, On 15/02/18 23:17, Stefano Stabellini wrote: Update the documentation of the hmp-unsafe option to explain how to use it safely, together with the right cpu affinity setting, on big.LITTLE

Re: [Xen-devel] [PATCH 3/4] xen/arm: set vpidr on the pcpu where the vcpu will run

On Fri, 16 Feb 2018, Julien Grall wrote: > On 16/02/2018 20:31, Stefano Stabellini wrote: > > On Fri, 16 Feb 2018, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 15/02/18 23:16, Stefano Stabellini wrote: > > > > On big.LITTLE systems not all cores have the same midr. Instead of > > > >

[Xen-devel] [linux-linus test] 119350: regressions - FAIL

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

Re: [Xen-devel] [PATCH 4/4] xen/arm: update the docs about heterogeneous computing

On Fri, 16 Feb 2018, Julien Grall wrote: > Hi Stefano, > > On 15/02/18 23:17, Stefano Stabellini wrote: > > Update the documentation of the hmp-unsafe option to explain how to use > > it safely, together with the right cpu affinity setting, on big.LITTLE > > systems. > > > > Also update the

Re: [Xen-devel] [RESEND v2] mm: don't defer struct page initialization for Xen pv guests

On Fri, 16 Feb 2018 16:41:01 +0100 Juergen Gross wrote: > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -347,6 +347,9 @@ static inline bool update_defer_init(pg_data_t *pgdat, > /* Always populate low zones for address-constrained allocations */ > if (zone_end <

Re: [Xen-devel] [RESEND v2] mm: don't defer struct page initialization for Xen pv guests

On Fri, 16 Feb 2018 16:41:01 +0100 Juergen Gross wrote: > Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing > memory during allocation in vmemmap") broke Xen pv domains in some > configurations, as the "Pinned" information in struct page of early > page tables

Re: [Xen-devel] [PATCH 3/4] xen/arm: set vpidr on the pcpu where the vcpu will run

On Fri, 16 Feb 2018, Julien Grall wrote: > Hi Stefano, > > On 15/02/18 23:16, Stefano Stabellini wrote: > > On big.LITTLE systems not all cores have the same midr. Instead of > > initializing the vpidr to the boot cpu midr, set it to the value of the > > midr of the pcpu where the vcpu will run.

Re: [Xen-devel] PV guest with PCI passthrough crash on Xen 4.8.3 inside KVM when booted through OVMF

On Fri, Feb 16, 2018 at 07:02:39PM +, Andrew Cooper wrote: > On 16/02/18 18:51, Marek Marczykowski-Górecki wrote: > > On Fri, Feb 16, 2018 at 05:52:50PM +, Andrew Cooper wrote: > >> On 16/02/18 17:48, Marek Marczykowski-Górecki wrote: > >>> Hi, > >>> > >>> As in the subject, the guest

Re: [Xen-devel] PV guest with PCI passthrough crash on Xen 4.8.3 inside KVM when booted through OVMF

On 16/02/18 18:51, Marek Marczykowski-Górecki wrote: > On Fri, Feb 16, 2018 at 05:52:50PM +, Andrew Cooper wrote: >> On 16/02/18 17:48, Marek Marczykowski-Górecki wrote: >>> Hi, >>> >>> As in the subject, the guest crashes on boot, before kernel output >>> anything. I've isolated this to the

Re: [Xen-devel] PV guest with PCI passthrough crash on Xen 4.8.3 inside KVM when booted through OVMF

On Fri, Feb 16, 2018 at 05:52:50PM +, Andrew Cooper wrote: > On 16/02/18 17:48, Marek Marczykowski-Górecki wrote: > > Hi, > > > > As in the subject, the guest crashes on boot, before kernel output > > anything. I've isolated this to the conditions below: > > - PV guest have PCI device

Re: [Xen-devel] [PATCH v2] tools: libxenstat: fix format string overflow

On Fri, Feb 16, 2018 at 07:38:48PM +0100, Dario Faggioli wrote: > With gcc 7.3.0, the build fails like this: > > src/xenstat_linux.c: In function ‘getBridge’ > src/xenstat_linux.c:78:34: warning: ‘%s’ directive writing up to 255 bytes > into a region of size 241 [-Wformat-overflow=] >

[Xen-devel] [PATCH v2] tools: libxenstat: fix format string overflow

With gcc 7.3.0, the build fails like this: src/xenstat_linux.c: In function ‘getBridge’ src/xenstat_linux.c:78:34: warning: ‘%s’ directive writing up to 255 bytes into a region of size 241 [-Wformat-overflow=] sprintf(tmp, "/sys/class/net/%s/bridge", de->d_name);

[Xen-devel] [seabios test] 119373: regressions - FAIL

flight 119373 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/119373/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539 Tests which did not

Re: [Xen-devel] [PATCH] tools: libxenstat: fix format string overflow

On Fri, 2018-02-16 at 17:58 +, Wei Liu wrote: > On Fri, Feb 16, 2018 at 06:55:08PM +0100, Dario Faggioli wrote: > > On Fri, 2018-02-16 at 17:44 +, Wei Liu wrote: > > > > > Right! And what do I do if it fails, 'continue' the while(), I > > guess? > > > > Looking at the error message

Re: [Xen-devel] [PATCH] tools: libxenstat: fix format string overflow

On Fri, Feb 16, 2018 at 06:55:08PM +0100, Dario Faggioli wrote: > On Fri, 2018-02-16 at 17:44 +, Wei Liu wrote: > > On Fri, Feb 16, 2018 at 06:36:51PM +0100, Dario Faggioli wrote: > > > > > > --- a/tools/xenstat/libxenstat/src/xenstat_linux.c > > > +++

Re: [Xen-devel] [PATCH] tools: libxenstat: fix format string overflow

On Fri, 2018-02-16 at 17:44 +, Wei Liu wrote: > On Fri, Feb 16, 2018 at 06:36:51PM +0100, Dario Faggioli wrote: > > > > --- a/tools/xenstat/libxenstat/src/xenstat_linux.c > > +++ b/tools/xenstat/libxenstat/src/xenstat_linux.c > > @@ -69,18 +69,20 @@ void getBridge(char *excludeName, char

Re: [Xen-devel] [PATCH] tools: libxenstat: fix format string overflow

On Fri, 2018-02-16 at 17:44 +, Wei Liu wrote: > On Fri, Feb 16, 2018 at 06:36:51PM +0100, Dario Faggioli wrote: > > > > --- a/tools/xenstat/libxenstat/src/xenstat_linux.c > > +++ b/tools/xenstat/libxenstat/src/xenstat_linux.c > > @@ -69,18 +69,20 @@ void getBridge(char *excludeName, char

Re: [Xen-devel] PV guest with PCI passthrough crash on Xen 4.8.3 inside KVM when booted through OVMF

On 16/02/18 17:48, Marek Marczykowski-Górecki wrote: > Hi, > > As in the subject, the guest crashes on boot, before kernel output > anything. I've isolated this to the conditions below: > - PV guest have PCI device assigned (e1000e emulated by QEMU in this case), >without PCI device it works

[Xen-devel] PV guest with PCI passthrough crash on Xen 4.8.3 inside KVM when booted through OVMF

Hi, As in the subject, the guest crashes on boot, before kernel output anything. I've isolated this to the conditions below: - PV guest have PCI device assigned (e1000e emulated by QEMU in this case), without PCI device it works - Xen (in KVM) is started through OVMF; with seabios it works

[Xen-devel] [PATCH v2] x86/nmi: start NMI watchdog on CPU0 after SMP bootstrap

We're noticing a reproducible system boot hang on certain post-Skylake platforms where the BIOS is configured in legacy boot mode with x2APIC disabled. The system stalls immediately after writing the first SMP initialization sequence into APIC ICR. The cause of the problem is watchdog NMI handler

Re: [Xen-devel] [PATCH] tools: libxenstat: fix format string overflow

On Fri, Feb 16, 2018 at 05:44:05PM +, Wei Liu wrote: > On Fri, Feb 16, 2018 at 06:36:51PM +0100, Dario Faggioli wrote: > > With gcc 7.3.0, the build fails like this: > > > > src/xenstat_linux.c: In function ‘getBridge’ > > src/xenstat_linux.c:78:34: warning: ‘%s’ directive writing up to 255

Re: [Xen-devel] [PATCH] tools: libxenstat: fix format string overflow

On Fri, Feb 16, 2018 at 06:36:51PM +0100, Dario Faggioli wrote: > With gcc 7.3.0, the build fails like this: > > src/xenstat_linux.c: In function ‘getBridge’ > src/xenstat_linux.c:78:34: warning: ‘%s’ directive writing up to 255 bytes > into a region of size 241 [-Wformat-overflow=] >

Re: [Xen-devel] [PATCH] mm: don't defer struct page initialization for Xen pv guests

On 02/16/2018 09:02 AM, Juergen Gross wrote: On 16/02/18 14:59, Michal Hocko wrote: [CC Pavel] On Fri 16-02-18 14:37:26, Juergen Gross wrote: Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing memory during allocation in vmemmap") broke Xen pv domains in some configurations,

Re: [Xen-devel] [PATCH] tools: libxenstat: fix format string overflow

On 16/02/18 17:36, Dario Faggioli wrote: > With gcc 7.3.0, the build fails like this: > > src/xenstat_linux.c: In function ‘getBridge’ > src/xenstat_linux.c:78:34: warning: ‘%s’ directive writing up to 255 bytes > into a region of size 241 [-Wformat-overflow=] > sprintf(tmp,

Re: [Xen-devel] [RFC PATCH 33/49] ARM: new VGIC: Add PRIORITY registers handlers

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: The priority register handlers are shared between the v2 and v3 emulation, so their implementation goes into vgic-mmio.c, to be easily referenced from the v3 emulation as well later. There is a corner case when we change the priority of a

[Xen-devel] [PATCH] tools: libxenstat: fix format string overflow

With gcc 7.3.0, the build fails like this: src/xenstat_linux.c: In function ‘getBridge’ src/xenstat_linux.c:78:34: warning: ‘%s’ directive writing up to 255 bytes into a region of size 241 [-Wformat-overflow=] sprintf(tmp, "/sys/class/net/%s/bridge", de->d_name);

Re: [Xen-devel] [RFC PATCH 32/49] ARM: new VGIC: Add ACTIVE registers handlers

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: The active register handlers are shared between the v2 and v3 emulation, so their implementation goes into vgic-mmio.c, to be easily referenced from the v3 emulation as well later. Since activation/deactivation of an interrupt may happen

Re: [Xen-devel] [RFC PATCH 31/49] ARM: new VGIC: Add PENDING registers handlers

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: The pending register handlers are shared between the v2 and v3 emulation, so their implementation goes into vgic-mmio.c, to be easily referenced from the v3 emulation as well later. For level triggered interrupts the real line level is

Re: [Xen-devel] [PATCH] x86: issue branch prediction barrier when switching 64-bit guest to kernel mode

On 16/02/18 15:39, Jan Beulich wrote: > Since both kernel and user mode run in ring 3, they run in the same > "predictor mode". While the kernel could take care of this itself, doing > so would be yet another item distinguishing PV from native. Additionally > we're in a much better position to

Re: [Xen-devel] [PATCH] x86/PV: avoid indirect call/thunk in I/O emulation

On 16/02/18 16:21, Jan Beulich wrote: On 16.02.18 at 16:50, wrote: >> On 16/02/18 08:00, Jan Beulich wrote: >> On 15.02.18 at 17:53, wrote: On 15/02/18 16:03, Jan Beulich wrote: > --- a/xen/arch/x86/pv/emul-priv-op.c >

Re: [Xen-devel] [RFC PATCH 30/49] ARM: new VGIC: Add ENABLE registers handlers

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: As the enable register handlers are shared between the v2 and v3 emulation, their implementation goes into vgic-mmio.c, to be easily referenced from the v3 emulation as well later. Signed-off-by: Andre Przywara ---

Re: [Xen-devel] [PATCH] shut down domain when last vCPU goes down

On 16/02/18 17:25, Jan Beulich wrote: On 16.02.18 at 16:52, wrote: >> On Fri, Feb 16, 2018 at 08:10:48AM -0700, Jan Beulich wrote: >>> I've just had to deal with an early boot crash of Linux which occurred >>> so early that even "earlyprintk=xen" did not produce any

Re: [Xen-devel] [PATCH] shut down domain when last vCPU goes down

>>> On 16.02.18 at 16:52, wrote: > On Fri, Feb 16, 2018 at 08:10:48AM -0700, Jan Beulich wrote: >> I've just had to deal with an early boot crash of Linux which occurred >> so early that even "earlyprintk=xen" did not produce any useful output. >> Hence the domain appeared

Re: [Xen-devel] [PATCH] x86/PV: avoid indirect call/thunk in I/O emulation

>>> On 16.02.18 at 16:50, wrote: > On 16/02/18 08:00, Jan Beulich wrote: > On 15.02.18 at 17:53, wrote: >>> On 15/02/18 16:03, Jan Beulich wrote: --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@

Re: [Xen-devel] [PATCH] shut down domain when last vCPU goes down

On Fri, Feb 16, 2018 at 03:59:45PM +, Wei Liu wrote: > On Fri, Feb 16, 2018 at 03:52:48PM +, Roger Pau Monné wrote: > > On Fri, Feb 16, 2018 at 08:10:48AM -0700, Jan Beulich wrote: > > > I've just had to deal with an early boot crash of Linux which occurred > > > so early that even

Re: [Xen-devel] [PATCH v1] x86/msr: add Raw and Host domain policies

On 16/02/18 16:00, Sergey Dyasli wrote: > On Fri, 2018-02-16 at 11:38 +, Andrew Cooper wrote: >> On 16/02/18 11:31, Sergey Dyasli wrote: >>> On Fri, 2018-02-16 at 04:06 -0700, Jan Beulich wrote: >>> On 16.02.18 at 11:33, wrote: > On Thu, 2018-02-15 at 06:33

Re: [Xen-devel] [PATCH v1] x86/msr: add Raw and Host domain policies

On Fri, 2018-02-16 at 11:38 +, Andrew Cooper wrote: > On 16/02/18 11:31, Sergey Dyasli wrote: > > On Fri, 2018-02-16 at 04:06 -0700, Jan Beulich wrote: > > > > > > On 16.02.18 at 11:33, wrote: > > > > > > > > On Thu, 2018-02-15 at 06:33 -0700, Jan Beulich wrote: > >

Re: [Xen-devel] [PATCH] shut down domain when last vCPU goes down

On Fri, Feb 16, 2018 at 03:52:48PM +, Roger Pau Monné wrote: > On Fri, Feb 16, 2018 at 08:10:48AM -0700, Jan Beulich wrote: > > I've just had to deal with an early boot crash of Linux which occurred > > so early that even "earlyprintk=xen" did not produce any useful output. > > Hence the

Re: [Xen-devel] [RFC PATCH 29/49] ARM: new VGIC: Add CTLR, TYPER and IIDR handlers

Hi, On 09/02/18 14:39, Andre Przywara wrote: Those three registers are v2 emulation specific, so their implementation lives entirely in vgic-mmio-v2.c. Also they are handled in one function, as their implementation is pretty simple. When the guest enables the distributor, we kick all VCPUs to

Re: [Xen-devel] [PATCH] shut down domain when last vCPU goes down

On Fri, Feb 16, 2018 at 08:10:48AM -0700, Jan Beulich wrote: > I've just had to deal with an early boot crash of Linux which occurred > so early that even "earlyprintk=xen" did not produce any useful output. > Hence the domain appeared to hang, while in fact it had brought down its > only vCPU. By

Re: [Xen-devel] [PATCH] x86/PV: avoid indirect call/thunk in I/O emulation

On 16/02/18 08:00, Jan Beulich wrote: On 15.02.18 at 17:53, wrote: >> On 15/02/18 16:03, Jan Beulich wrote: >>> --- a/xen/arch/x86/pv/emul-priv-op.c >>> +++ b/xen/arch/x86/pv/emul-priv-op.c >>> @@ -73,55 +73,42 @@ void (*pv_post_outb_hook)(unsigned int p >>> >>>

[Xen-devel] [RESEND v2] mm: don't defer struct page initialization for Xen pv guests

Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing memory during allocation in vmemmap") broke Xen pv domains in some configurations, as the "Pinned" information in struct page of early page tables could get lost. This will lead to the kernel trying to write directly into the page

Re: [Xen-devel] [RFC PATCH 28/49] ARM: new VGIC: Add GICv2 MMIO handling framework

Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: Create vgic-mmio-v2.c to describe GICv2 emulation specific handlers using the initializer macros provided by the VGIC MMIO framework. Provide a function to register the GICv2 distributor registers to the Xen MMIO framework. The actual handler

[Xen-devel] [PATCH] x86: issue branch prediction barrier when switching 64-bit guest to kernel mode

Since both kernel and user mode run in ring 3, they run in the same "predictor mode". While the kernel could take care of this itself, doing so would be yet another item distinguishing PV from native. Additionally we're in a much better position to issue the barrier command, and we can save a #GP

Re: [Xen-devel] [RFC PATCH 27/49] ARM: new VGIC: Add MMIO handling framework

Hi Andre, On 13/02/18 18:17, Andre Przywara wrote: On 13/02/18 16:52, Julien Grall wrote: +struct vgic_register_region { +    unsigned int reg_offset; +    unsigned int len; +    unsigned int bits_per_irq; +    unsigned int access_flags; +    union +    { +    unsigned long (*read)(struct

Re: [Xen-devel] [RFC PATCH 24/49] ARM: new VGIC: Add IRQ sync/flush framework

On 13/02/18 15:40, Andre Przywara wrote: Hi, On 13/02/18 12:41, Julien Grall wrote: Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: gets called on guest entry and exit. The code talking to the actual GICv2/v3 hardware is added in the following patches. This is based on Linux commit

[Xen-devel] [PATCH v2] mm: don't defer struct page initialization for Xen pv guests

Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing memory during allocation in vmemmap") broke Xen pv domains in some configurations, as the "Pinned" information in struct page of early page tables could get lost. This will lead to the kernel trying to write directly into the page

Re: [Xen-devel] [PATCH] shut down domain when last vCPU goes down

On 16/02/18 15:10, Jan Beulich wrote: > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -1321,6 +1321,22 @@ long do_vcpu_op(int cmd, unsigned int vc > break; > > case VCPUOP_down: > +for_each_vcpu ( d, v ) > +if ( v->vcpu_id != vcpuid &&

Re: [Xen-devel] [RFC PATCH 21/49] ARM: new VGIC: Add acccessor to new struct vgic_irq instance

On 13/02/18 11:18, Andre Przywara wrote: Hi, Hi Andre, On 12/02/18 17:42, Julien Grall wrote: Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: The new VGIC implementation centers around a struct vgic_irq instance per virtual IRQ. Provide a function to retrieve the right instance for

[Xen-devel] [PATCH] shut down domain when last vCPU goes down

I've just had to deal with an early boot crash of Linux which occurred so early that even "earlyprintk=xen" did not produce any useful output. Hence the domain appeared to hang, while in fact it had brought down its only vCPU. By translating this to a shutdown, the situation will be better

Re: [Xen-devel] [RFC PATCH 15/49] ARM: GIC: Allow tweaking the active state of an IRQ

On 13/02/18 15:01, Andre Przywara wrote: Hi, Hi Andre, On 13/02/18 12:02, Julien Grall wrote: On 12/02/18 17:53, Andre Przywara wrote: Hi, Hi Andre, On 12/02/18 13:55, Julien Grall wrote: Hi Andre, On 09/02/18 14:39, Andre Przywara wrote: When playing around with hardware mapped,

Re: [Xen-devel] [PATCH v2 2/2] vmx/hap: optimize CR4 trapping

On 02/16/2018 02:39 PM, Razvan Cojocaru wrote: > On 02/16/2018 02:37 PM, Roger Pau Monné wrote: >> On Fri, Feb 16, 2018 at 02:30:55PM +0200, Razvan Cojocaru wrote: >>> On 02/16/2018 02:10 PM, Roger Pau Monne wrote: diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c index

[Xen-devel] [PATCH v2] xen/arm: vgic: Make sure the number of SPIs is a multiple of 32

The vGIC relies on having a pending_irq available for every IRQs described in the ranks. As each rank describes 32 interrupts, we need to make sure the number of SPIs is a multiple of 32. Reported-by: Jeff Kubascik Signed-off-by: Julien Grall

[Xen-devel] [xen-4.8-testing test] 119273: tolerable FAIL - PUSHED

flight 119273 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/119273/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-2 49 xtf/test-hvm64-lbr-tsx-vmentry fail like 118818 test-xtf-amd64-amd64-3 49

Re: [Xen-devel] [PATCH] xen/arm: vgic: Make sure the number of SPIs is a multiple of 32

(+ Jarvis) Hmmm it looks like my modification in git-send-email to take CC all *-by tags disappeared. So CC jarvis. Cheers, On 16/02/18 14:35, Julien Grall wrote: The vGIC relies on having a pending_irq available for every IRQs described in the ranks. As each rank describes 32 interrupts,

[Xen-devel] [PATCH] xen/arm: vgic: Make sure the number of SPIs is a multiple of 32

The vGIC relies on having a pending_irq available for every IRQs described in the ranks. As each rank describes 32 interrupts, we need to make sure the number of SPIs is a multiple of 32. Reported-by: Jarvis Roach Signed-off-by: Julien Grall

Re: [Xen-devel] [PATCH] mm: don't defer struct page initialization for Xen pv guests

On Fri 16-02-18 15:02:17, Juergen Gross wrote: > On 16/02/18 14:59, Michal Hocko wrote: > > [CC Pavel] > > > > On Fri 16-02-18 14:37:26, Juergen Gross wrote: > >> Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing > >> memory during allocation in vmemmap") broke Xen pv domains in

Re: [Xen-devel] [PATCH] mm: don't defer struct page initialization for Xen pv guests

On 16/02/18 14:59, Michal Hocko wrote: > [CC Pavel] > > On Fri 16-02-18 14:37:26, Juergen Gross wrote: >> Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing >> memory during allocation in vmemmap") broke Xen pv domains in some >> configurations, as the "Pinned" information in

[Xen-devel] [PATCH] mm: don't defer struct page initialization for Xen pv guests

Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing memory during allocation in vmemmap") broke Xen pv domains in some configurations, as the "Pinned" information in struct page of early page tables could get lost. Avoid this problem by not deferring struct page initialization when

Re: [Xen-devel] [PATCH] Propagate microcode update errors

On Fr, 2018-02-16 at 13:19 +, Peter Lawthers wrote: > From: Uwe Dannowski > > Errors on updating the microcode in the processor were silently > dropped when invoked via the microcode_update hypercall. Also, the > log > message was misleading. > > Signed-off-by: Uwe

Re: [Xen-devel] [PATCH] Propagate microcode update errors

On 16/02/18 13:19, Peter Lawthers wrote: > From: Uwe Dannowski > > Errors on updating the microcode in the processor were silently > dropped when invoked via the microcode_update hypercall. Also, the log > message was misleading. > > Signed-off-by: Uwe Dannowski >

Re: [Xen-devel] [PATCH v2 1/2] x86/hvm: introduce cr_mask to store trapped bits of CR accesses

On 16/02/18 12:10, Roger Pau Monne wrote: > diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h > index d93166fb92..811d4c10ae 100644 > --- a/xen/include/asm-x86/hvm/vcpu.h > +++ b/xen/include/asm-x86/hvm/vcpu.h > @@ -156,6 +156,9 @@ struct hvm_vcpu { > */ >

Re: [Xen-devel] [PATCH v2 2/2] vmx/hap: optimize CR4 trapping

On 02/16/2018 02:37 PM, Roger Pau Monné wrote: > On Fri, Feb 16, 2018 at 02:30:55PM +0200, Razvan Cojocaru wrote: >> On 02/16/2018 02:10 PM, Roger Pau Monne wrote: >>> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c >>> index f229e69948..4317658c56 100644 >>> ---

Re: [Xen-devel] [PATCH v2 2/2] vmx/hap: optimize CR4 trapping

On Fri, Feb 16, 2018 at 02:30:55PM +0200, Razvan Cojocaru wrote: > On 02/16/2018 02:10 PM, Roger Pau Monne wrote: > > diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c > > index f229e69948..4317658c56 100644 > > --- a/xen/arch/x86/monitor.c > > +++ b/xen/arch/x86/monitor.c > > @@

Re: [Xen-devel] [PATCH v2 2/2] vmx/hap: optimize CR4 trapping

On 02/16/2018 02:10 PM, Roger Pau Monne wrote: > diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c > index f229e69948..4317658c56 100644 > --- a/xen/arch/x86/monitor.c > +++ b/xen/arch/x86/monitor.c > @@ -189,10 +189,11 @@ int arch_monitor_domctl_event(struct domain *d, >

Re: [Xen-devel] [PATCH] hvm/monitor: fix usage of the control register mask

On 02/16/2018 02:18 PM, Roger Pau Monne wrote: > Previous usage is not correct and would prevent certain updates from > being notified to the monitor client. > > For example if (value ^ old) == (PGE | PSE) and mask == PGE this > update would not be notified. > > Signed-off-by: Roger Pau Monné

[Xen-devel] [PATCH] hvm/monitor: fix usage of the control register mask

Previous usage is not correct and would prevent certain updates from being notified to the monitor client. For example if (value ^ old) == (PGE | PSE) and mask == PGE this update would not be notified. Signed-off-by: Roger Pau Monné --- Cc: Razvan Cojocaru

[Xen-devel] [PATCH v2 2/2] vmx/hap: optimize CR4 trapping

There a bunch of bits in CR4 that should be allowed to be set directly by the guest without requiring Xen intervention, currently this is already done by passing through guest writes into the CR4 used when running in non-root mode, but taking an expensive vmexit in order to do so. xenalyze

[Xen-devel] [PATCH v2 0/2] vmx/hap: optimize CR4 trapping

Hello, Following two-patch series optimize CR4 access for vmx/hap. I couldn't figure out a similar approach for AMD, since according to section 15.9 (Instruction Intercepts), you either intercept all access to CR4 or none. In any case a similar optimization for AMD can always be added later.

[Xen-devel] [PATCH v2 1/2] x86/hvm: introduce cr_mask to store trapped bits of CR accesses

At the moment this is currently set at VMCS creation and not changed, but further patches are going to change the CR4 mask at runtime. Signed-off-by: Roger Pau Monné --- Cc: Boris Ostrovsky Cc: Suravee Suthikulpanit

Re: [Xen-devel] [PATCH 0/4] unsafe big.LITTLE support

On 15/02/18 23:16, Stefano Stabellini wrote: Hi all, Hi Stefano, This series changes the initialization of two virtual registers to make sure they match the value of the underlying physical cpu. It also disables cpus different from the boot cpu, unless a newly introduced command line

Re: [Xen-devel] [PATCH] vmx/hap: optimize CR4 trapping

On 02/16/2018 01:25 PM, Roger Pau Monné wrote: > On Thu, Feb 15, 2018 at 09:32:00PM +0200, Razvan Cojocaru wrote: >> On 02/15/2018 08:57 PM, Andrew Cooper wrote: >>> On 15/02/18 16:25, Roger Pau Monne wrote: There a bunch of bits in CR4 that should be allowed to be set directly by the

Re: [Xen-devel] Xen-Project apply | Outreachy (interest in 1. High-level Language Support with Unikraft / 2. Xen on ARM: create multiple guests from device tree)

Hi Rupal, I CC'ed two lists and the mentors of projects. Thank you for your interest in the projects. > I went through > https://www.outreachy.org/2018-may-august/communities/xen-project/ > project page and could see that each of these two projects has their own set > of mentors > (2 each,

Re: [Xen-devel] [PATCH v1] x86/msr: add Raw and Host domain policies

On 16/02/18 11:31, Sergey Dyasli wrote: > On Fri, 2018-02-16 at 04:06 -0700, Jan Beulich wrote: > On 16.02.18 at 11:33, wrote: >>> On Thu, 2018-02-15 at 06:33 -0700, Jan Beulich wrote: >>> On 08.02.18 at 11:23, wrote: > uint64_t

Re: [Xen-devel] [PATCH v1] x86/msr: add Raw and Host domain policies

>>> On 16.02.18 at 12:31, wrote: > On Fri, 2018-02-16 at 04:06 -0700, Jan Beulich wrote: >> > > > On 16.02.18 at 11:33, wrote: >> > >> > On Thu, 2018-02-15 at 06:33 -0700, Jan Beulich wrote: >> > > > > > On 08.02.18 at 11:23,

Re: [Xen-devel] [PATCH v1] x86/msr: add Raw and Host domain policies

On Fri, 2018-02-16 at 04:06 -0700, Jan Beulich wrote: > > > > On 16.02.18 at 11:33, wrote: > > > > On Thu, 2018-02-15 at 06:33 -0700, Jan Beulich wrote: > > > > > > On 08.02.18 at 11:23, wrote: > > > > > > > > uint64_t val; > > > > +

Re: [Xen-devel] [PATCH] vmx/hap: optimize CR4 trapping

On Thu, Feb 15, 2018 at 09:32:00PM +0200, Razvan Cojocaru wrote: > On 02/15/2018 08:57 PM, Andrew Cooper wrote: > > On 15/02/18 16:25, Roger Pau Monne wrote: > >> There a bunch of bits in CR4 that should be allowed to be set directly > >> by the guest without requiring Xen intervention, currently

Re: [Xen-devel] [PATCH 4/4] xen/arm: update the docs about heterogeneous computing

Hi Stefano, On 15/02/18 23:17, Stefano Stabellini wrote: Update the documentation of the hmp-unsafe option to explain how to use it safely, together with the right cpu affinity setting, on big.LITTLE systems. Also update the warning message to point users to the docs. Signed-off-by: Stefano

Re: [Xen-devel] [PATCH V5] x86/hvm: fix domain crash when CR3 has the noflush bit set

>>> On 16.02.18 at 11:22, wrote: > The emulation layers of Xen lack PCID support, and as we only offer > PCID to HAP guests, all writes to CR3 are handled by hardware, > except when introspection is involved. Consequently, trying to set > CR3 when the noflush bit is set

[Xen-devel] [xen-4.7-testing test] 119251: regressions - trouble: blocked/broken/fail/pass

flight 119251 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/119251/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt broken build-armhf-libvirt 4

Re: [Xen-devel] [PATCH v1] x86/msr: add Raw and Host domain policies

>>> On 16.02.18 at 11:33, wrote: > On Thu, 2018-02-15 at 06:33 -0700, Jan Beulich wrote: >> > > > On 08.02.18 at 11:23, wrote: >> >uint64_t val; >> > + int rc; >> > >> > - if (rdmsr_safe(MSR_INTEL_PLATFORM_INFO, val) || >> > + if ((rc

Re: [Xen-devel] [PATCH 3/4] xen/arm: set vpidr on the pcpu where the vcpu will run

Hi Stefano, On 15/02/18 23:16, Stefano Stabellini wrote: On big.LITTLE systems not all cores have the same midr. Instead of initializing the vpidr to the boot cpu midr, set it to the value of the midr of the pcpu where the vcpu will run. This way, assuming that the vcpu has been created with

Re: [Xen-devel] [PATCH 2/4] xen/arm: read ACTLR on the pcpu where the vcpu will run

Hi Stefano, On 15/02/18 23:16, Stefano Stabellini wrote: On big.LITTLE systems not all cores have the same ACTLR. Instead of reading ACTLR and setting v->arch.actlr in vcpu_initialise, which is run always on pcpu 0, do it later on the same pcpu where the vcpu will run. While the Hardware

Re: [Xen-devel] Slow HVM boot time, was "HVM boot time optimization"

On Fri, 16 Feb 2018 09:05:02 +0100 Yessine Daoud wrote: >Hello, > >Please find attached the requested log file. According to the log, string I/O is actually passed from IOREQ buffered -- in groups of 4096 I/O read ops, but they're still emulated one by one, calling QEMU's

[Xen-devel] [PATCH] osstest: add a pvinpvh test

The new shim tests uses the same approach as the PVH one, but doesn't differentiate between AMD and Intel. This is the (trimmed) diff of the output from mg-show-flight-runvars: +test-amd64-amd64-xl-pvshimall_host_di_version2017-12-14 +test-amd64-i386-xl-pvshim all_host_di_version

  1   2   >