[Xen-devel] [PATCH 1/2] x86: include the PPIN in MCE records when available

Quoting the respective Linux commit: Intel Xeons from Ivy Bridge onwards support a processor identification number set in the factory. To the user this is a handy unique number to identify a particular CPU. Intel can decode this to the fab/production run to track errors. On

Re: [Xen-devel] [PATCH v2] x86/passthrough: fix migration of MSI when using posted interrupts

On Tue, Oct 29, 2019 at 05:20:18PM -0700, Joe Jin wrote: > Hi Roger & Jan, > > I got my test env back, and back the patch to stable-4.12, run same > test, I still seen original issue, guest kernel printed error: > > kernel:do_IRQ: 20.114 No irq handler for vector (irq -1) > > After that, pass

Re: [Xen-devel] [PATCH v3 00/20] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge

Hi Aleksandar, On 10/27/19 8:44 AM, Aleksandar Markovic wrote: On Saturday, October 26, 2019, Philippe Mathieu-Daudé > wrote: Changes since v2 [0]: - Use a #define - Reword one description - Added review tags (thanks all for reviewing!) Changes

Re: [Xen-devel] [XEN PATCH for-4.13 v2 2/4] libxl: gentypes.py: Break out field_pass in ..._copy_deprecated

On Tue, Oct 29, 2019 at 03:54:34PM +, Ian Jackson wrote: > We are going to want this in a moment. > > No functional change with existing types: C output is identical. > > Signed-off-by: Ian Jackson Acked-by: Anthony PERARD -- Anthony PERARD

Re: [Xen-devel] [XEN PATCH for-4.13 v2 4/4] libxl: gentypes: initialise array elements in json

On Tue, Oct 29, 2019 at 03:54:36PM +, Ian Jackson wrote: > diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py > index 124285cd66..c74445f16e 100644 > --- a/tools/libxl/gentypes.py > +++ b/tools/libxl/gentypes.py > @@ -461,6 +461,10 @@ def libxl_C_type_parse_json(ty, w, v, indent =

[Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm testid debian-hvm-install Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

Re: [Xen-devel] [PATCH v3 2/7] xen/nospec: Use always_inline to fix code gen for evaluate_nospec

On 29.10.2019 17:53, Andrew Cooper wrote: > On 25/10/2019 13:03, Jan Beulich wrote: >> On 23.10.2019 15:58, Andrew Cooper wrote: >>> evaluate_nospec() is incredibly fragile, and this is one giant bodge. >>> >>> To correctly protect jumps, the generated code needs to be of the form: >>> >>>

[Xen-devel] [PATCH v3] x86: clear RDRAND CPUID bit on AMD family 15h/16h

Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24: There have been reports of RDRAND issues after resuming from suspend on some AMD family 15h and family 16h systems. This issue stems from a BIOS not performing the proper steps during resume to ensure RDRAND continues

Re: [Xen-devel] [XEN PATCH for-4.13 v2 3/4] libxl: gentypes.py: Break out libxl_C_type_do_init

On Tue, Oct 29, 2019 at 03:54:35PM +, Ian Jackson wrote: > This is going to be the common way to initialise things. > _libxl_C_type_init remains the thing for generating the body of the > init function, and for some special cases. > > No functional change with existing types: C output is

[Xen-devel] [libvirt test] 143316: regressions - FAIL

flight 143316 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/143316/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 143023

Re: [Xen-devel] [PATCH v3 5/7] x86/livepatch: Fail the build if duplicate symbols exist

On 29.10.2019 18:06, Andrew Cooper wrote: > On 24/10/2019 13:03, Jan Beulich wrote: >> On 23.10.2019 15:58, Andrew Cooper wrote: >>> --- a/xen/common/Kconfig >>> +++ b/xen/common/Kconfig >>> @@ -361,9 +361,23 @@ config FAST_SYMBOL_LOOKUP >>> >>> If unsure, say Y. >>> >>> +config

[Xen-devel] [xen-unstable-coverity test] 143396: all pass - PUSHED

flight 143396 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/143396/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen f51d4a19427674491eaecef85c551613450188c5 baseline version: xen

[Xen-devel] [PATCH 0/2] x86: Protected Processor Inventory Number (PPIN) support

1: include the PPIN in MCE records when available 2: explicitly disallow guest access to PPIN I will also see to get around to post the Linux side consumer patch of the interface addition in patch 1. Jan ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH v3 5/7] x86/livepatch: Fail the build if duplicate symbols exist

On 30/10/2019 08:41, Jan Beulich wrote: > On 29.10.2019 18:06, Andrew Cooper wrote: >> On 24/10/2019 13:03, Jan Beulich wrote: >>> On 23.10.2019 15:58, Andrew Cooper wrote: --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -361,9 +361,23 @@ config FAST_SYMBOL_LOOKUP

Re: [Xen-devel] [xen-4.12-testing test] 143302: regressions - FAIL

On 29.10.2019 23:52, osstest service owner wrote: > flight 143302 xen-4.12-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/143302/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

[Xen-devel] [PATCH 2/2] x86: explicitly disallow guest access to PPIN

To fulfill the "protected" in its name, don't let the real hardware values "shine through". Report a control register value expressing this. Signed-off-by: Jan Beulich --- TBD: Do we want to permit Dom0 access? --- a/xen/arch/x86/msr.c +++ b/xen/arch/x86/msr.c @@ -135,6 +135,8 @@ int

Re: [Xen-devel] [XEN PATCH for-4.13 v2 1/4] tools/libxl: gentypes.py: Prefer init_val to init_fn

On Tue, Oct 29, 2019 at 03:54:33PM +, Ian Jackson wrote: > When both are provided, init_val is likely to be more direct. > > No functional change with existing types: C output is identical. > > Signed-off-by: Ian Jackson Acked-by: Anthony PERARD -- Anthony PERARD

Re: [Xen-devel] [PATCH v3 5/7] x86/livepatch: Fail the build if duplicate symbols exist

On 30.10.2019 11:37, Andrew Cooper wrote: > On 30/10/2019 08:41, Jan Beulich wrote: >> On 29.10.2019 18:06, Andrew Cooper wrote: >>> On 24/10/2019 13:03, Jan Beulich wrote: On 23.10.2019 15:58, Andrew Cooper wrote: > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -361,9

[Xen-devel] [linux-4.19 test] 143326: regressions - FAIL

flight 143326 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/143326/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 12 guest-start/redhat.repeat fail REGR. vs. 142932

[Xen-devel] [linux-4.14 test] 143327: regressions - FAIL

flight 143327 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/143327/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 142849

[Xen-devel] [PATCH v2 for 4.13 2/2] x86/e820: fix 640k - 1M region reservation logic

Converting a guest from PV to PV-in-PVH makes the guest to have 384k less memory, which may confuse guest's balloon driver. This happens because Xen unconditionally reserves 640k - 1M region in E820 despite the fact that it's really a usable RAM in PVH boot mode. Fix this by skipping region type

[Xen-devel] [PATCH v2 for 4.13 1/2] x86/boot: allow early usage of cpu_has_hypervisor

Move early_cpu_init() to be near the top of __start_xen(). Since there is no serial / vga output at that stage, introduce a new function to print CPU information at the usual place during boot. Finally, convert users of cpuid_ecx(1) & X86_FEATURE_HYPERVISOR. Signed-off-by: Sergey Dyasli --- CC:

[Xen-devel] [PATCH v1] x86/hvm: Update code in HVMOP_altp2m_set_suppress_ve

Originally the gfn and altp2m_idx are assigned from the a.u.mem_access union. This works because it's the same memory used. This patch addresses this issue by changing the mem_access union with the suppress_ve union for consistency. Signed-off-by: Alexandru Isaila --- xen/arch/x86/hvm/hvm.c | 4

Re: [Xen-devel] [PATCH v3 00/20] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge

> > In case you, for any reason, can't complete this by softfreeze, I advice >> you not to rush, and postpone the integration to 5.0. >> > > This series doesn't provide any useful feature, it is a simple cleanup, > posted and reviewed before soft freeze, so we still have 1 week (until > hard

Re: [Xen-devel] [PATCH v1] x86/hvm: Update code in HVMOP_altp2m_set_suppress_ve

On 30/10/2019 13:02, Alexandru Stefan ISAILA wrote: > Originally the gfn and altp2m_idx are assigned from the a.u.mem_access union. > This works because it's the same memory used. This patch addresses this > issue by changing the mem_access union with the suppress_ve union for > consistency. > >

Re: [Xen-devel] [PATCH 2/2] x86: explicitly disallow guest access to PPIN

On 30/10/2019 10:39, Jan Beulich wrote: > To fulfill the "protected" in its name, don't let the real hardware > values "shine through". Report a control register value expressing this. > > Signed-off-by: Jan Beulich > --- > TBD: Do we want to permit Dom0 access? I would recommend reordering the

Re: [Xen-devel] [PATCH 2/2] x86: explicitly disallow guest access to PPIN

On 30.10.2019 12:43, Andrew Cooper wrote: > On 30/10/2019 10:39, Jan Beulich wrote: >> To fulfill the "protected" in its name, don't let the real hardware >> values "shine through". Report a control register value expressing this. >> >> Signed-off-by: Jan Beulich >> --- >> TBD: Do we want to

Re: [Xen-devel] [PATCH v3 00/20] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge

Patchew URL: https://patchew.org/QEMU/20191026180143.7369-1-phi...@redhat.com/ Hi, This series seems to have some coding style problems. See output below for more information: Subject: [Xen-devel] [PATCH v3 00/20] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge Type: series

Re: [Xen-devel] [PATCH v1] x86/hvm: Update code in HVMOP_altp2m_set_suppress_ve

On 30.10.2019 15:14, Andrew Cooper wrote: > On 30/10/2019 13:02, Alexandru Stefan ISAILA wrote: >> Originally the gfn and altp2m_idx are assigned from the a.u.mem_access union. >> This works because it's the same memory used. This patch addresses this >> issue by changing the mem_access union with

Re: [Xen-devel] Xen-unstable: AMD-Vi: update_paging_mode Try to access pdev_list without aquiring pcidevs_lock.

On 28.10.2019 11:32, Sander Eikelenboom wrote: > While testing the latest xen-unstable and starting an HVM guest with > pci-passtrough on my AMD machine, > my eye catched the following messages in xl dmesg I haven't seen before: > > (XEN) [2019-10-28 10:23:16.372] AMD-Vi: update_paging_mode Try

[Xen-devel] [PATCH 08/12] driver: xen: Replace cpu_up/down with device_online/offline

The core device API performs extra housekeeping bits that are missing from directly calling cpu_up/down. See commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and serialization during LPM") for an example description of what might go wrong. This also prepares to make cpu_up/down a

[Xen-devel] [PATCH 00/12] Convert cpu_up/down to device_online/offline

Using cpu_up/down directly to bring cpus online/offline loses synchronization with sysfs and could suffer from a race similar to what is described in commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and serialization during LPM"). cpu_up/down seem to be more of a internal implementation

[Xen-devel] [OSSTEST PATCH] xl guest creation: Pause 10s to work around libxl/blkback races

In ea6626f7edd9eb40a3510eaf6816a77cac4f63d0 guest_prepare_disk: Only do the umount if we set an env var we removed (in the usual case) a check for the guest disk already being mounted in dom0 etc. This check is there for ad-hoc testing. We removed it because it exposes what we think is an

Re: [Xen-devel] [PATCH v2 for 4.13 1/2] x86/boot: allow early usage of cpu_has_hypervisor

On 30/10/2019 15:32, Jan Beulich wrote: > On 30.10.2019 15:54, Sergey Dyasli wrote: >> @@ -317,11 +316,6 @@ void __init early_cpu_init(void) >> c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx; >> c->x86_capability[cpufeat_word(X86_FEATURE_SSE3)] = ecx; >> >> -

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

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemut-ws16-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: ovmf

Re: [Xen-devel] [PATCH v2] x86/passthrough: fix migration of MSI when using posted interrupts

On 10/30/19 1:24 AM, Roger Pau Monné wrote: > Can you try to add the following debug patch on top of the existing > one and report the output that you get on the Xen console? Applied debug patch and run the test again, not of any log printed, attached Xen log on serial console, seems

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

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

Re: [Xen-devel] [PATCH v2] x86/passthrough: fix migration of MSI when using posted interrupts

On 10/30/19 10:23 AM, Roger Pau Monné wrote: > On Wed, Oct 30, 2019 at 09:38:16AM -0700, Joe Jin wrote: >> On 10/30/19 1:24 AM, Roger Pau Monné wrote: >>> Can you try to add the following debug patch on top of the existing >>> one and report the output that you get on the Xen console? >> >>

[Xen-devel] rochester boot loader serial output issue (was Re: [xen-unstable test] 143061: regressions - trouble: broken/fail/pass)

Stefano Stabellini writes ("Re: [Xen-devel] [xen-unstable test] 143061: regressions - trouble: broken/fail/pass"): > And I do have a suggestion for somebody else to pick this up: Brian > (CC'ed) has joined Xilinx recently and might be willing to help on this. > However, we would need to give him

Re: [Xen-devel] [PATCH v2 for 4.13 1/2] x86/boot: allow early usage of cpu_has_hypervisor

On 30.10.2019 15:54, Sergey Dyasli wrote: > @@ -317,11 +316,6 @@ void __init early_cpu_init(void) > c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx; > c->x86_capability[cpufeat_word(X86_FEATURE_SSE3)] = ecx; > > - printk(XENLOG_INFO > -"CPU Vendor: %s, Family

Re: [Xen-devel] [PATCH v2 for 4.13 2/2] x86/e820: fix 640k - 1M region reservation logic

On 30.10.2019 15:54, Sergey Dyasli wrote: > Converting a guest from PV to PV-in-PVH makes the guest to have 384k > less memory, which may confuse guest's balloon driver. This happens > because Xen unconditionally reserves 640k - 1M region in E820 despite > the fact that it's really a usable RAM in

Re: [Xen-devel] [osstest test] 143311: regressions - FAIL

osstest service owner writes ("[osstest test] 143311: regressions - FAIL"): > flight 143311 osstest real [real] > http://logs.test-lab.xenproject.org/osstest/logs/143311/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

Re: [Xen-devel] Xen >4.10 bricks onboard NIC of Dell Optiplex 7060

Running Xen Dom0-less leaves the NIC intact, so you're correct in assessing that Xen by itself is not the cause. As for running without the driver, I'm not sure that's possible (at least for my competency). It uses the Intel Base Gigabit driver that's built into the kernel. And running the

[Xen-devel] [linux-4.9 test] 143328: regressions - FAIL

flight 143328 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/143328/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 142947

[Xen-devel] [XEN PATCH for-4.13 v2 3/6] libxl: Rename ev_devlock to ev_slowlock

We are going to introduce a different lock based on the same implementation as the ev_devlock but with a different path. The different slowlock will be differentiated by calling different _init() functions. So we rename libxl__ev_devlock to lib__ev_slowlock, but keep libxl__ev_devlock_init().

[Xen-devel] [XEN PATCH for-4.13 v2 2/6] libxl: Move libxl__ev_devlock declaration

We are going to want to include libxl__ev_devlock into libxl__ev_qmp. No functional changes. Signed-off-by: Anthony PERARD --- Notes: New patch in v2: Move of the struct was done in "libxl_qmp: Have a lock for QMP socket access" before. tools/libxl/libxl_internal.h | 96

[Xen-devel] [XEN PATCH for-4.13 v2 5/6] libxl: libxl__ev_qmp_send now takes an egc

No functionnal changes. Signed-off-by: Anthony PERARD Acked-by: Ian Jackson --- tools/libxl/libxl_disk.c| 6 +++--- tools/libxl/libxl_dm.c | 8 tools/libxl/libxl_dom_save.c| 2 +- tools/libxl/libxl_dom_suspend.c | 2 +- tools/libxl/libxl_domain.c | 8

[Xen-devel] [XEN PATCH for-4.13 v2 6/6] libxl_qmp: Have a lock for QMP socket access

This patch workaround the fact that it's not possible to connect multiple time to a single QMP socket. QEMU listen on the socket with a backlog value of 1, which mean that on Linux when concurrent thread call connect() on the socket, they get EAGAIN. Background: This happens when attempting

[Xen-devel] [XEN PATCH for-4.13 v2 4/6] libxl: Introduce libxl__ev_slowlock_dispose

Which allow to cancel the lock operation while it is in Active state. Signed-off-by: Anthony PERARD --- Notes: v2: - Renamed libxl__ev_qmplock_dispose to libxl__ev_slowlock_dispose - This new API was part of the patch "Introduce libxl__ev_qmplock" in v1.

[Xen-devel] [XEN PATCH for-4.13 v2 0/6] Fix: libxl workaround, multiple connection to single QMP socket

Patch series available in this git branch: https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git br.fix-ev_qmp-multi-connect-v2 Hi, QEMU's QMP socket doesn't allow multiple concurrent connection. Also, it listen() on the socket with a `backlog' of only 1. On Linux at least, once that

[Xen-devel] [XEN PATCH for-4.13 v2 1/6] libxl: Introduce libxl__ev_child_kill_deregister

Allow to deregister the callback associated with a child death event. The death isn't immediate will need to be collected later, so the ev_child machinery register its own callback. libxl__ev_child_kill_deregister() might be called by an AO operation that is finishing/cleaning up without a

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

flight 143330 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/143330/ 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. 142994

Re: [Xen-devel] [PATCH v2 09/15] xen/gntdev: use mmu_range_notifier_insert

On 10/28/19 4:10 PM, Jason Gunthorpe wrote: > From: Jason Gunthorpe > > gntdev simply wants to monitor a specific VMA for any notifier events, > this can be done straightforwardly using mmu_range_notifier_insert() over > the VMA's VA range. > > The notifier should be attached until the original

Re: [Xen-devel] [PATCH v2] x86/passthrough: fix migration of MSI when using posted interrupts

On Wed, Oct 30, 2019 at 09:38:16AM -0700, Joe Jin wrote: > On 10/30/19 1:24 AM, Roger Pau Monné wrote: > > Can you try to add the following debug patch on top of the existing > > one and report the output that you get on the Xen console? > > Applied debug patch and run the test again, not of any

[Xen-devel] [ovmf test] 143348: all pass - PUSHED

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

[Xen-devel] [libvirt bisection] complete test-amd64-i386-libvirt-pair

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-libvirt-pair testid guest-start/debian Tree: libvirt git://libvirt.org/libvirt.git Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/ Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git Tree: linux

[Xen-devel] [xtf test] 143358: all pass - PUSHED

flight 143358 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/143358/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf f20237784839c65f2b6ea0bfad1c472d0b101d3e baseline version: xtf

[Xen-devel] [linux-4.4 test] 143351: regressions - FAIL

flight 143351 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/143351/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 139698

Re: [Xen-devel] [XEN PATCH for-4.13 v2 0/6] Fix: libxl workaround, multiple connection to single QMP socket

On 30/10/2019 19:06, Anthony PERARD wrote: > Patch series available in this git branch: > https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git > br.fix-ev_qmp-multi-connect-v2 > > Hi, > > QEMU's QMP socket doesn't allow multiple concurrent connection. Also, it > listen() on the

Re: [Xen-devel] Xen-unstable: AMD-Vi: update_paging_mode Try to access pdev_list without aquiring pcidevs_lock.

On 30/10/2019 16:48, Jan Beulich wrote: > On 28.10.2019 11:32, Sander Eikelenboom wrote: >> While testing the latest xen-unstable and starting an HVM guest with >> pci-passtrough on my AMD machine, >> my eye catched the following messages in xl dmesg I haven't seen before: >> >> (XEN) [2019-10-28

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

flight 143360 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/143360/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-bootfail REGR. vs. 142750