Re: [Xen-devel] [PATCH v5 00/16] Xen ARM DomU ACPI support

On 09/15/2016 04:58 AM, Julien Grall wrote: > Hi Boris, > > On 15/09/2016 03:17, Boris Ostrovsky wrote: >> >> - julien.gr...@arm.com wrote: >> >>> Hi Stefano, >>> >>> On 14/09/2016 21:48, Stefano Stabellini wrote: On Wed, 14 Sep 2016, Julien Grall wrote: > On 14/09/2016 02:06, Stefano

Re: [Xen-devel] [for-4.8][PATCH v2 22/23] xen/arm: p2m: Do not handle shattering in p2m_create_table

Hi, On 15/09/2016 12:28, Julien Grall wrote: The helper p2m_create_table is only called to create a brand new table. Signed-off-by: Julien Grall Reviewd-by: Stefano Stabellini I made 2 typoes here. It should be: Reviewed-by: Stefano Stabellini

Re: [Xen-devel] [PATCH V4] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On Thu, Sep 15, 2016 at 04:52:32PM +0300, Razvan Cojocaru wrote: > On 09/15/2016 04:49 PM, Wei Liu wrote: > > On Thu, Sep 15, 2016 at 04:39:47PM +0300, Razvan Cojocaru wrote: > >> On 09/07/2016 07:01 PM, Jan Beulich wrote: > >> On 07.09.16 at 11:12, wrote: >

Re: [Xen-devel] [PATCH V4] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On 09/15/2016 04:55 PM, Wei Liu wrote: > On Thu, Sep 15, 2016 at 04:52:32PM +0300, Razvan Cojocaru wrote: >> On 09/15/2016 04:49 PM, Wei Liu wrote: >>> On Thu, Sep 15, 2016 at 04:39:47PM +0300, Razvan Cojocaru wrote: On 09/07/2016 07:01 PM, Jan Beulich wrote: On 07.09.16 at 11:12,

Re: [Xen-devel] [Qemu-devel] [RFC] e1000: Don't save writes to ICS/ICR masked by IMS

On 09/15/2016 03:22 PM, Ed Swierk wrote: > On Thu, Sep 15, 2016 at 2:15 AM, Denis V. Lunev wrote: >> On 09/13/2016 11:59 PM, Konrad Rzeszutek Wilk wrote: >>> On Thu, Sep 01, 2016 at 10:57:48AM -0700, Ed Swierk wrote: Windows 8, 10 and Server 2012 guests hang intermittently

Re: [Xen-devel] [PATCH V4] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On Thu, Sep 15, 2016 at 04:39:47PM +0300, Razvan Cojocaru wrote: > On 09/07/2016 07:01 PM, Jan Beulich wrote: > On 07.09.16 at 11:12, wrote: > >> Currently it is only possible to set mem_access restrictions only for > >> a contiguous range of GFNs (or, as a

Re: [Xen-devel] [RFC] e1000: Don't save writes to ICS/ICR masked by IMS

On Thu, Sep 15, 2016 at 2:15 AM, Denis V. Lunev wrote: > On 09/13/2016 11:59 PM, Konrad Rzeszutek Wilk wrote: > > On Thu, Sep 01, 2016 at 10:57:48AM -0700, Ed Swierk wrote: > >> Windows 8, 10 and Server 2012 guests hang intermittently while booting > >> on Xen 4.5.3 with 1 vCPU

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

Hi Boris, On 15/09/2016 13:39, Boris Ostrovsky wrote: On 09/15/2016 06:22 AM, Wei Liu wrote: On Thu, Sep 15, 2016 at 11:20:08AM +0100, Julien Grall wrote: Hi Wei, On 15/09/2016 11:18, Wei Liu wrote: On Wed, Sep 14, 2016 at 11:21:39AM -0400, Boris Ostrovsky wrote: On 09/07/2016 02:59 PM,

Re: [Xen-devel] [PATCH v5 00/16] Xen ARM DomU ACPI support

On 15/09/2016 13:35, Boris Ostrovsky wrote: On 09/15/2016 04:58 AM, Julien Grall wrote: I think Jan mentioned at some point that certain versions of Windows require an early revision although IIRC it was 2.0. So perhaps at some point we could drop support for pre-2.0 versions, but this was

Re: [Xen-devel] [RFC PATCH] xen-netback: fix error handling on netback_probe()

On Thu, Sep 15, 2016 at 04:05:17PM +0200, Filipe Manco wrote: > On 14-09-2016 12:10, Wei Liu wrote: > >CC xen-devel as well. > > > >On Tue, Sep 13, 2016 at 02:11:27PM +0200, Filipe Manco wrote: > >>In case of error during netback_probe() (e.g. an entry missing on the > >>xenstore) netback_remove()

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

On 09/15/2016 06:22 AM, Wei Liu wrote: > On Thu, Sep 15, 2016 at 11:20:08AM +0100, Julien Grall wrote: >> Hi Wei, >> >> On 15/09/2016 11:18, Wei Liu wrote: >>> On Wed, Sep 14, 2016 at 11:21:39AM -0400, Boris Ostrovsky wrote: On 09/07/2016 02:59 PM, Boris Ostrovsky wrote: > The goal here

[Xen-devel] [ovmf baseline-only test] 67717: all pass

This run is configured for baseline tests only. flight 67717 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67717/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf f8db6527da8678f1480f08ba99b745279e8d104a baseline

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

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

[Xen-devel] [xen-unstable baseline-only test] 67714: tolerable FAIL

This run is configured for baseline tests only. flight 67714 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67714/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-i386-pvgrub 10 guest-start

Re: [Xen-devel] [PATCH V4] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On 09/07/2016 07:01 PM, Jan Beulich wrote: On 07.09.16 at 11:12, wrote: >> Currently it is only possible to set mem_access restrictions only for >> a contiguous range of GFNs (or, as a particular case, for a single GFN). >> This patch introduces a new libxc

Re: [Xen-devel] [PATCH V4] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On 09/15/2016 04:49 PM, Wei Liu wrote: > On Thu, Sep 15, 2016 at 04:39:47PM +0300, Razvan Cojocaru wrote: >> On 09/07/2016 07:01 PM, Jan Beulich wrote: >> On 07.09.16 at 11:12, wrote: Currently it is only possible to set mem_access restrictions only for a

Re: [Xen-devel] [RFC PATCH] xen-netback: fix error handling on netback_probe()

On 14-09-2016 12:10, Wei Liu wrote: CC xen-devel as well. On Tue, Sep 13, 2016 at 02:11:27PM +0200, Filipe Manco wrote: In case of error during netback_probe() (e.g. an entry missing on the xenstore) netback_remove() is called on the new device, which will set the device backend state to

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

On 09/15/2016 09:48 AM, Julien Grall wrote: > Hi Boris, > > On 15/09/2016 13:39, Boris Ostrovsky wrote: >> On 09/15/2016 06:22 AM, Wei Liu wrote: >>> On Thu, Sep 15, 2016 at 11:20:08AM +0100, Julien Grall wrote: Hi Wei, On 15/09/2016 11:18, Wei Liu wrote: > On Wed, Sep 14, 2016

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

On 09/15/2016 10:21 AM, Jan Beulich wrote: On 15.09.16 at 16:07, wrote: >> On 09/15/2016 09:48 AM, Julien Grall wrote: >>> On 15/09/2016 13:39, Boris Ostrovsky wrote: One option could be to provide a 'gpl_all' (or some such) target in libacpi in addition

Re: [Xen-devel] [PATCH 6/6] docs: add HVM USB passthrough documentation

On Thu, Sep 08, 2016 at 09:20:26AM +0200, Juergen Gross wrote: > Update the man page regarding passthrough of USB devices to HVM > domains via qemu USB emulation. > > Signed-off-by: Juergen Gross Acked-by: Wei Liu

Re: [Xen-devel] [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation

On Wed, Sep 14, 2016 at 11:58 PM, Jan Beulich wrote: On 14.09.16 at 18:20, wrote: >> On Wed, Sep 14, 2016 at 9:55 AM, Jan Beulich wrote: >> On 13.09.16 at 20:12, wrote: When emulating

[Xen-devel] [xen-unstable test] 100965: tolerable FAIL - PUSHED

flight 100965 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100965/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100960

Re: [Xen-devel] [PATCH 5/6] libxl: add HVM usb passthrough support

On Thu, Sep 08, 2016 at 09:20:25AM +0200, Juergen Gross wrote: > Add HVM usb passthrough support to libxl by using qemu's capability > to emulate standard USB controllers. > > A USB controller is added via qmp command to the emulated hardware > when a usbctrl device of type DEVICEMODEL is

Re: [Xen-devel] per-domain logging

On Thu, 2016-09-15 at 16:11 +0100, Wei Liu wrote: > On Thu, Sep 15, 2016 at 03:50:25PM +0100, Wei Liu wrote: > > > > CC Ian who might have some ideas on this. > > > > On Wed, Sep 14, 2016 at 04:22:24PM +0200, Cedric Bosdonnat wrote: > > > > > > Hi all, > > > > > > I wanted to get libvirt's

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

>>> On 15.09.16 at 17:28, wrote: > Something along the lines of this (attached as well to prevent line > wrapping) Looks reasonable with some polishing (GPL=y on the make lines and using C_SRC-$(GPL) and CSRC-y). > Maybe even without changes to mk_dsdt.c But isn't

Re: [Xen-devel] [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation

>>> On 15.09.16 at 17:27, wrote: > On Wed, Sep 14, 2016 at 11:58 PM, Jan Beulich wrote: > On 14.09.16 at 18:20, wrote: >>> On Wed, Sep 14, 2016 at 9:55 AM, Jan Beulich wrote: >>> On 13.09.16

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

On Wed, Sep 14, 2016 at 11:21:39AM -0400, Boris Ostrovsky wrote: > On 09/07/2016 02:59 PM, Boris Ostrovsky wrote: > > The goal here is to build ACPI tables for PVHv2/HVMlite guests while > > reusing existing > > hvmloader's ACPI builder code. The builder is provided as a library in > >

Re: [Xen-devel] Xen virtual IOMMU high level design doc

Hi Andrew: Sorry to bother you. To make sure we are on the right direction, it's better to get feedback from you before we go further step. Could you have a look? Thanks. On 8/17/2016 8:05 PM, Lan, Tianyu wrote: Hi All: The following is our Xen vIOMMU high level design for detail

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

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

Re: [Xen-devel] [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation

On Wed, Sep 14, 2016 at 1:58 AM, Razvan Cojocaru wrote: > On 09/13/2016 09:12 PM, Tamas K Lengyel wrote: >> When emulating instructions the emulator maintains a small i-cache fetched >> from the guest memory. This patch extends the vm_event interface to allow >>

[Xen-devel] [PATCH v2 1/2] vm_event: Sanitize vm_event response handling

Setting response flags in vm_event are only ever safe if the vCPUs are paused. To reflect this we move all checks within the if block that already checks whether this is the case. Checks that are only supported on one architecture we relocate the bitmask operations to the arch-specific handlers to

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

On 09/15/2016 12:05 PM, Jan Beulich wrote >> Maybe even without changes to mk_dsdt.c > But isn't that the critical part? Not necessarily since we'd use --gpl option only for dsdt_anycpu_qemu_xen, dsdt_anycpu and dsdt_15cpu and these files are not used by the non-GPL caller, which is libxl (it

[Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

When emulating instructions Xen's emulator maintains a small i-cache fetched from the guest memory. This patch extends the vm_event interface to allow overwriting this i-cache via a buffer returned in the vm_event response. When responding to a SOFTWARE_BREAKPOINT event (INT3) the monitor

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

flight 100966 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100966/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100951 test-amd64-amd64-xl-rtds

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

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

Re: [Xen-devel] [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation

On 09/15/16 19:36, Tamas K Lengyel wrote: > On Wed, Sep 14, 2016 at 1:58 AM, Razvan Cojocaru > wrote: >> On 09/13/2016 09:12 PM, Tamas K Lengyel wrote: >>> When emulating instructions the emulator maintains a small i-cache fetched >>> from the guest memory. This patch

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

On 9/13/2016 11:25 PM, Jan Beulich wrote: Wait - what is do_invalid_op() doing on the stack? I don't think it belongs there, and hence I wonder whether the keypress happened after some already fatal event (in which case all bets are off anyway). Not clear why do_invalid_op() on the stack.

Re: [Xen-devel] per-domain logging

On Thu, Sep 15, 2016 at 03:50:25PM +0100, Wei Liu wrote: > CC Ian who might have some ideas on this. > > On Wed, Sep 14, 2016 at 04:22:24PM +0200, Cedric Bosdonnat wrote: > > Hi all, > > > > I wanted to get libvirt's libxl driver have per-domain logs like all other > > drivers. After > >

[Xen-devel] [PATCH v2] xen-netback: fix error handling on netback_probe()

In case of error during netback_probe() (e.g. an entry missing on the xenstore) netback_remove() is called on the new device, which will set the device backend state to XenbusStateClosed by calling set_backend_state(). However, the backend state wasn't initialized by netback_probe() at this point,

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

>>> On 15.09.16 at 16:07, wrote: > On 09/15/2016 09:48 AM, Julien Grall wrote: >> On 15/09/2016 13:39, Boris Ostrovsky wrote: >>> One option could be to provide a 'gpl_all' (or some such) target in >>> libacpi in addition to 'all' and that target will be careful about

Re: [Xen-devel] [PATCH 5/6] libxl: add HVM usb passthrough support

On Fri, Sep 09, 2016 at 12:13:46PM +0200, Juergen Gross wrote: > On 09/09/16 12:00, Wei Liu wrote: > > On Thu, Sep 08, 2016 at 09:20:25AM +0200, Juergen Gross wrote: > >> Add HVM usb passthrough support to libxl by using qemu's capability > >> to emulate standard USB controllers. > >> > >> A USB

Re: [Xen-devel] per-domain logging

CC Ian who might have some ideas on this. On Wed, Sep 14, 2016 at 04:22:24PM +0200, Cedric Bosdonnat wrote: > Hi all, > > I wanted to get libvirt's libxl driver have per-domain logs like all other > drivers. After > looking at the libxl and XenToolLogger it seems I'll need to add the feature >

Re: [Xen-devel] [PATCH 4/6] libxl: add basic support for devices without backend

On Thu, Sep 08, 2016 at 09:20:24AM +0200, Juergen Gross wrote: > With the planned support of HVM USB passthrough via the USB emulation > capabilities of qemu libxl has to support guest devices which have no > back- and frontend. Information about those devices will live in the > libxl part of

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

>>> On 15.09.16 at 16:16, wrote: > On 9/13/2016 11:25 PM, Jan Beulich wrote: >> Wait - what is do_invalid_op() doing on the stack? I don't think it >> belongs there, and hence I wonder whether the keypress >> happened after some already fatal event (in which case all bets >>

Re: [Xen-devel] [for-4.8][PATCH v2 00/23] xen/arm: Rework the P2M code to follow break-before-make sequence

On Thu, Sep 15, 2016 at 5:28 AM, Julien Grall wrote: > Hello all, > > The ARM architecture mandates the use of a break-before-make sequence when > changing translation entries if the page table is shared between multiple > CPUs whenever a valid entry is replaced by another

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich wrote: On 15.09.16 at 12:05, wrote: >> On 14/09/16 22:01, Kyle Huey wrote: >>> Xen advertises the underlying support for CPUID faulting but not does pass >>> through writes to the relevant MSR, nor does

[Xen-devel] [PATCH v3] vm_event: Implement ARM SMC events

The ARM SMC instructions are already configured to trap to Xen by default. In this patch we allow a user-space process in a privileged domain to receive notification of when such event happens through the vm_event subsystem by introducing the PRIVILEGED_CALL type. The intended use-case for this

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Thu, Sep 15, 2016 at 12:11 PM, Kyle Huey wrote: > On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich wrote: > On 15.09.16 at 12:05, wrote: >>> On 14/09/16 22:01, Kyle Huey wrote: Xen advertises the underlying support for CPUID

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On 09/15/2016 03:11 PM, Kyle Huey wrote: > On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich wrote: > On 15.09.16 at 12:05, wrote: >>> On 14/09/16 22:01, Kyle Huey wrote: Xen advertises the underlying support for CPUID faulting but not does pass

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Thu, Sep 15, 2016 at 1:38 PM, H. Peter Anvin wrote: > On September 14, 2016 6:17:51 PM PDT, Andy Lutomirski > wrote: >>On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey wrote: >>> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen >>>

Re: [Xen-devel] [PATCH v3 3/3] x86, arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey wrote: > Intel supports faulting on the CPUID instruction in newer processors. Bit > 31 of MSR_PLATFORM_INFO advertises support for this feature. It is > documented in detail in Section 2.3.2 of >

[Xen-devel] [qemu-mainline test] 100971: regressions - FAIL

flight 100971 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100971/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 100966

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

flight 100970 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100970/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail REGR. vs. 100965

[Xen-devel] [PATCH v3] arch_prctl, x86 Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

rr (http://rr-project.org/), a userspace record-and-replay reverse- execution debugger, would like to trap and emulate the CPUID instruction. This would allow us to a) mask away certain hardware features that rr does not support (e.g. RDRAND) and b) enable trace portability across machines by

[Xen-devel] [PATCH v3 3/3] x86, arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

Intel supports faulting on the CPUID instruction in newer processors. Bit 31 of MSR_PLATFORM_INFO advertises support for this feature. It is documented in detail in Section 2.3.2 of

[Xen-devel] [PATCH v3 1/3] syscalls, x86 Expose arch_prctl on x86-32.

arch_prctl is currently 64-bit only. Wire it up for 32-bits, as a no-op for now. Rename the second arg to a more generic name. Signed-off-by: Kyle Huey --- arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/include/asm/proto.h | 5 -

[Xen-devel] [PATCH v3 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

Signed-off-by: Kyle Huey --- arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/msr-index.h | 1 + arch/x86/kernel/cpu/scattered.c| 14 ++ 3 files changed, 16 insertions(+) diff --git a/arch/x86/include/asm/cpufeatures.h

Re: [Xen-devel] [PATCH v3 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey wrote: Reviewed-by: Andy Lutomirski although this is really Borislav's domain. OTOH, if you're planning on changing Linux's Xen MSR helpers to mask the feature out, that should be in the same patch or an earlier

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Thu, Sep 15, 2016 at 12:37 PM, Andy Lutomirski wrote: > On Thu, Sep 15, 2016 at 12:11 PM, Kyle Huey wrote: >> On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich wrote: >> On 15.09.16 at 12:05, wrote: On

[Xen-devel] [qemu-mainline baseline-only test] 67719: regressions - FAIL

This run is configured for baseline tests only. flight 67719 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67719/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-xsm 6 xen-boot

[Xen-devel] [xen-unstable baseline-only test] 67718: regressions - FAIL

This run is configured for baseline tests only. flight 67718 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67718/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-pair 9

Re: [Xen-devel] [PATCH v3 3/3] x86, arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

On Thu, Sep 15, 2016 at 5:07 PM, Andy Lutomirski wrote: > On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey wrote: >> +int get_cpuid_mode(unsigned long adr) >> +{ >> + unsigned int val; >> + >> + if (test_thread_flag(TIF_NOCPUID)) >> +

Re: [Xen-devel] [Help] Trigger Watchdog when adding an IPI in vcpu_wake

On Wed, Sep 14, 2016 at 06:18:48PM +0200, Dario Faggioli wrote: >On Wed, 2016-09-14 at 18:44 +0800, Wei Yang wrote: >> On Tue, Sep 13, 2016 at 01:30:17PM +0200, Dario Faggioli wrote: >> >  >> > Do you mind sharing just a bit more, such as: >> >  - number of pcpus >> >  - number of vcpus of the

Re: [Xen-devel] [PATCH v3 1/3] syscalls, x86 Expose arch_prctl on x86-32.

On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey wrote: > arch_prctl is currently 64-bit only. Wire it up for 32-bits, as a no-op for > now. Rename the second arg to a more generic name. > > Signed-off-by: Kyle Huey > --- > arch/x86/entry/syscalls/syscall_32.tbl

[Xen-devel] [ovmf baseline-only test] 67720: all pass

This run is configured for baseline tests only. flight 67720 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67720/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 490acf8908f797982f367bfeb4bdf3ebe0764e42 baseline

Re: [Xen-devel] [PATCH 06/17] x86emul: add EVEX decoding

>>> On 14.09.16 at 19:05, wrote: > On 08/09/16 14:12, Jan Beulich wrote: >> --- a/xen/arch/x86/x86_emulate/x86_emulate.c >> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c >> @@ -336,6 +336,27 @@ union vex { >> ptr[1] = rex | REX_PREFIX; \ >> } while (0) >> >>

Re: [Xen-devel] [PATCH 08/17] x86emul: generate and make use of canonical opcode representation

>>> On 14.09.16 at 19:30, wrote: >> @@ -435,6 +438,51 @@ struct x86_emulate_ctxt >> void *data; >> }; >> >> +/* >> + * This encodes the opcode extension in a "natural" way: > > I am not sure what you mean by natural way here. All you seem to mean > is that you

Re: [Xen-devel] [PATCH V1] xen/arm: domain_build: introduce dom0_lowmem bootargs

On Thu, Sep 15, 2016 at 08:20:33AM +0800, Peng Fan wrote: > Hi Edgar, > On Wed, Sep 14, 2016 at 04:16:58PM +0200, Edgar E. Iglesias wrote: > >On Wed, Sep 14, 2016 at 08:40:09PM +0800, Peng Fan wrote: > >> On Wed, Sep 14, 2016 at 01:34:10PM +0100, Julien Grall wrote: > >> > > >> > > >> >On 14/09/16

Re: [Xen-devel] [PATCH v4 1/2] xen: replace complicated tlbflush check with an inline function

>>> On 15.09.16 at 00:36, wrote: >> I don't think you should pass this into the function ... >> >> > +{ >> > +return page->u.free.need_tlbflush && >> > + page->tlbflush_timestamp <= tlbflush_current_time && >> >> ... and use tlbflush_current_time() here

[Xen-devel] [libvirt test] 100962: tolerable FAIL - PUSHED

flight 100962 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/100962/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13

Re: [Xen-devel] [PATCH 09/17] SVM: use generic instruction decoding

>>> On 14.09.16 at 19:56, wrote: > On 08/09/16 14:14, Jan Beulich wrote: >> int __get_instruction_length_from_list(struct vcpu *v, >> const enum instruction_index *list, unsigned int list_count) >> { >> struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb; >>

Re: [Xen-devel] [PATCH v4 1/2] xen: replace complicated tlbflush check with an inline function

>>> On 15.09.16 at 08:47, wrote: >> > I rewrite the inline function in xen/include/xen/mm.h to: >> > >> > +#include >> > + >> > +static inline bool accumulate_tlbflush(bool need_tlbflush, >> > + const struct page_info *page, >> > +

Re: [Xen-devel] [PATCH] x86: fold code in load_segments()

>>> On 14.09.16 at 19:12, wrote: > On 14/09/16 16:24, Jan Beulich wrote: >> --- a/xen/arch/x86/domain.c >> +++ b/xen/arch/x86/domain.c >> @@ -1745,22 +1745,22 @@ static void load_segments(struct vcpu *n >> (unsigned long *)pv->kernel_sp; >>

Re: [Xen-devel] [PATCH v4 1/2] xen: replace complicated tlbflush check with an inline function

> > I rewrite the inline function in xen/include/xen/mm.h to: > > > > +#include > > + > > +static inline bool accumulate_tlbflush(bool need_tlbflush, > > + const struct page_info *page, > > + uint32_t tlbflush_timestamp)

Re: [Xen-devel] [PATCH] x86: fold code in load_segments()

On 15/09/2016 07:28, Jan Beulich wrote: On 14.09.16 at 19:12, wrote: >> On 14/09/16 16:24, Jan Beulich wrote: >>> --- a/xen/arch/x86/domain.c >>> +++ b/xen/arch/x86/domain.c >>> @@ -1745,22 +1745,22 @@ static void load_segments(struct vcpu *n >>>

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On September 14, 2016 6:17:51 PM PDT, Andy Lutomirski wrote: >On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey wrote: >> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen >> wrote: >>> On 09/14/2016 02:01 PM, Kyle Huey wrote: > >>> Is

Re: [Xen-devel] [PATCH v5 00/16] Xen ARM DomU ACPI support

Hi Boris, On 15/09/2016 03:17, Boris Ostrovsky wrote: - julien.gr...@arm.com wrote: Hi Stefano, On 14/09/2016 21:48, Stefano Stabellini wrote: On Wed, 14 Sep 2016, Julien Grall wrote: On 14/09/2016 02:06, Stefano Stabellini wrote: On Wed, 14 Sep 2016, Shannon Zhao wrote: On

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On 14/09/16 22:01, Kyle Huey wrote: > Xen advertises the underlying support for CPUID faulting but not does pass > through writes to the relevant MSR, nor does it virtualize it, so it does > not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO. Could you clarify in the commit

Re: [Xen-devel] [PATCH v3 16/19] libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests

On Wed, Sep 07, 2016 at 02:59:26PM -0400, Boris Ostrovsky wrote: > Signed-off-by: Boris Ostrovsky Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 17/19] ilibxl: Initialize domain build info before calling libxl__domain_make

On Wed, Sep 07, 2016 at 02:59:27PM -0400, Boris Ostrovsky wrote: > libxl__domain_make() may want to use b_info so we should set defaults > a little earlier. > > Signed-off-by: Boris Ostrovsky Acked-by: Wei Liu

Re: [Xen-devel] [PATCH v3 19/19] libxc/xc_dom_core: Copy ACPI tables to guest space

On Wed, Sep 07, 2016 at 02:59:29PM -0400, Boris Ostrovsky wrote: > Load ACPI modules into guest space > > Signed-off-by: Boris Ostrovsky Some coding style issues are found. > --- > Changes in v3: > * Use more macros in first_high_idx intilalization. > * Format

Re: [Xen-devel] [PATCH v3 14/19] libxc/libxl: Allow multiple ACPI modules

On Wed, Sep 07, 2016 at 02:59:24PM -0400, Boris Ostrovsky wrote: > Provide ability to load multiple ACPI modules. Thie feature is needed > by PVHv2 guests and will be used in subsequent patches. > > We assume that PVHv2 guests do not load their ACPI modules specified > in the configuration file.

Re: [Xen-devel] [RFC 20/22] xen/arm: p2m: Re-implement p2m_insert_mapping using p2m_set_entry

Hi Stefano, On 06/09/2016 19:57, Stefano Stabellini wrote: On Thu, 28 Jul 2016, Julien Grall wrote: The function p2m_insert_mapping can be re-implemented using the generic function p2m_set_entry. Note that the mapping is not reverted anymore if Xen fails to insert a mapping. This was added to

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

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

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On 14/09/16 22:35, Dave Hansen wrote: > On 09/14/2016 02:01 PM, Kyle Huey wrote: >> Xen advertises the underlying support for CPUID faulting but not does pass >> through writes to the relevant MSR, nor does it virtualize it, so it does >> not actually work. For now mask off the relevant bit on

Re: [Xen-devel] [PATCH v3] libxl: add "xl qemu-monitor-command"

On Fri, Sep 09, 2016 at 11:05:19AM +0100, Wei Liu wrote: > On Tue, Sep 06, 2016 at 02:16:30PM +0200, Dario Faggioli wrote: > > On Tue, 2016-09-06 at 12:51 +0200, Juergen Gross wrote: > > > Add a new xl command "qemu-monitor-command" to issue arbitrary > > > commands > > > to a domain's device

Re: [Xen-devel] [PATCH V1] xen/arm: domain_build: introduce dom0_lowmem bootargs

Hi, On 15/09/2016 09:26, Edgar E. Iglesias wrote: On Thu, Sep 15, 2016 at 08:20:33AM +0800, Peng Fan wrote: Hi Edgar, On Wed, Sep 14, 2016 at 04:16:58PM +0200, Edgar E. Iglesias wrote: On Wed, Sep 14, 2016 at 08:40:09PM +0800, Peng Fan wrote: On Wed, Sep 14, 2016 at 01:34:10PM +0100, Julien

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

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

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

>>> On 15.09.16 at 12:05, wrote: > On 14/09/16 22:01, Kyle Huey wrote: >> Xen advertises the underlying support for CPUID faulting but not does pass >> through writes to the relevant MSR, nor does it virtualize it, so it does >> not actually work. For now mask off the

[Xen-devel] [for-4.8][PATCH v2 00/23] xen/arm: Rework the P2M code to follow break-before-make sequence

Hello all, The ARM architecture mandates the use of a break-before-make sequence when changing translation entries if the page table is shared between multiple CPUs whenever a valid entry is replaced by another valid entry (see D4.7.1 in ARM DDI 0487A.j for more details). The current P2M code

[Xen-devel] [for-4.8][PATCH v2 13/23] xen/arm: p2m: Replace all usage of __p2m_lookup with p2m_get_entry

__p2m_lookup is just a wrapper to p2m_get_entry. Signed-off-by: Julien Grall Acked-by: Stefano Stabellini --- It might be possible to rework the memaccess code to take advantage of all the parameters. I will defer this to the memaccess

[Xen-devel] [for-4.8][PATCH v2 01/23] xen/arm: do_trap_instr_abort_guest: Move the IPA computation out of the switch

A follow-up patch will add more case to the switch that will require the IPA. So move the computation out of the switch. Signed-off-by: Julien Grall Acked-by: Stefano Stabellini --- Changes in v2: - Add Stefano's acked-by ---

[Xen-devel] [for-4.8][PATCH v2 09/23] xen/arm: p2m: Change the type of level_shifts from paddr_t to uint8_t

The level shift can be encoded with 8-bit. So it is not necessary to use paddr_t (i.e 64-bit). Signed-off-by: Julien Grall --- Changes in v2: - Use uint8_t rather than unsigned int - Replaced paddr_t by uint8_t in p2m_shatter_page ---

[Xen-devel] [for-4.8][PATCH v2 08/23] xen/arm: p2m: Invalidate the TLBs when write unlocking the p2m

Sometimes the invalidation of the TLBs can be deferred until the p2m is unlocked. This is for instance the case when multiple mappings are removed. In other case, such as shattering a superpage, an immediate flush is required. Keep track whether a flush is needed directly in the p2m_domain

[Xen-devel] [for-4.8][PATCH v2 06/23] xen/arm: traps: Move MMIO emulation code in a separate helper

Currently, a stage-2 fault translation will likely access an emulated region. All the checks are pre-sanitity check for MMIO emulation. A follow-up patch will handle a new case that could lead to a stage-2 translation. To improve the clarity of the code and the changes, the current implementation

[Xen-devel] [for-4.8][PATCH v2 07/23] xen/arm: traps: Check the P2M before injecting a data/instruction abort

A data/instruction abort may have occurred if another CPU was playing with the stage-2 page table when following the break-before-make sequence (see D4.7.1 in ARM DDI 0487A.j). Rather than injecting directly the fault to the guest, we need to check whether the mapping exists. If it exists, return

[Xen-devel] [for-4.8][PATCH v2 12/23] xen/arm: p2m: Introduce p2m_get_entry and use it to implement __p2m_lookup

Currently, for a given GFN, the function __p2m_lookup will only return the associated MFN and the p2m type of the mapping. In some case we need the order of the mapping and the memaccess permission. Rather than providing a separate function for this purpose, it is better to implement a generic

[Xen-devel] [for-4.8][PATCH v2 17/23] xen/arm: p2m: Introduce p2m_set_entry and __p2m_set_entry

The ARM architecture mandates to use of a break-before-make sequence when changing translation entries if the page table is shared between multiple CPUs whenever a valid entry is replaced by another valid entry (see D4.7.1 in ARM DDI 0487A.j for more details). The break-before-make sequence can

[Xen-devel] [for-4.8][PATCH v2 18/23] xen/arm: p2m: Re-implement relinquish_p2m_mapping using p2m_{get, set}_entry

The function relinquish_p2m_mapping can be re-implemented using p2m_{get,set}_entry by iterating over the range mapped and using the mapping order given by the callee. Given that the preemption was chosen arbitrarily, it is now done on every 512 iterations. Meaning that Xen may check more often

[Xen-devel] [for-4.8][PATCH v2 16/23] xen/arm: p2m: Introduce a helper to check if an entry is a superpage

Use the level and the entry to know whether an entry is a superpage. A superpage can only happen below level 3. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- Changes in v2: - Use bool instead of bool_t - Add

  1   2   >