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

flight 120098 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120098/ 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

Re: [Xen-devel] [PATCH v2 7/7] x86/build: Use new .nop directive when available

On 28/02/18 16:22, Jan Beulich wrote: On 26.02.18 at 12:35, wrote: >> Newer versions of binutils are capable of emitting an exact number bytes >> worth >> of optimised nops. Use this in preference to .skip when available. >> >> Signed-off-by: Andrew Cooper

Re: [Xen-devel] PVH backports to 4.9 and 4.8

> George Dunlap: >> /On 01/23/2018 04:06 AM, Simon Gaiser wrote:/ >> /> George Dunlap:/ >> />> Part of our solution to XSA-254 SP3 (aka "Meltdown") is to backport/ >> />> the PVH mode from 4.10 to 4.9 and 4.8. This will first allow people/ >> />> able to run PVH kernels to switch their PV guests

[Xen-devel] [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

The start info structure that is defined as part of the x86/HVM direct boot ABI and used for starting Xen PVH guests would be more versatile if it also included a way to pass information about the memory map to the guest. This would allow KVM guests to share the same entry point. Signed-off-by:

Re: [Xen-devel] [PATCH 2/6] x86/hvm: Handle viridian MSRs via the new guest_{rd, wr}msr() infrastructure

On 27/02/18 14:13, Roger Pau Monné wrote: > On Mon, Feb 26, 2018 at 05:35:15PM +, Andrew Cooper wrote: >> @@ -173,11 +175,26 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr, >> uint64_t *val) >> _MSR_MISC_FEATURES_CPUID_FAULTING; >> break; >> >> +case

Re: [Xen-devel] [PATCH 2/6] x86/hvm: Handle viridian MSRs via the new guest_{rd, wr}msr() infrastructure

On 27/02/18 14:38, Paul Durrant wrote: >> @@ -698,13 +697,11 @@ void viridian_time_ref_count_thaw(struct domain >> *d) >> trc->off = (int64_t)trc->val - raw_trc_val(d); >> } >> >> -int rdmsr_viridian_regs(uint32_t idx, uint64_t *val) >> +int guest_rdmsr_viridian(const struct vcpu *v,

Re: [Xen-devel] [PATCH] xen/pirq: fix error path cleanup when binding MSIs

On 28/02/18 10:19, Roger Pau Monne wrote: > Current cleanup in the error path of xen_bind_pirq_msi_to_irq is > wrong. First of all there's an off-by-one in the cleanup loop, which > can lead to unbinding wrong IRQs. > > Secondly IRQs not bound won't be freed, thus leaking IRQ numbers. > > Note

Re: [Xen-devel] [PATCH 8/9] drm/xen-front: Implement GEM operations

On 02/27/2018 01:52 AM, Oleksandr Andrushchenko wrote: > On 02/27/2018 01:47 AM, Boris Ostrovsky wrote: >> On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote: >>> On 02/23/2018 05:26 PM, Boris Ostrovsky wrote: On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote: >> > +    ret =

Re: [Xen-devel] [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

On Wed, Feb 28, 2018 at 10:28:00AM -0800, Maran Wilson wrote: > We need to refactor PVH entry code so that support for other hypervisors > like Qemu/KVM can be added more easily. > > This patch moves the small block of code used for initializing Xen PVH > virtual machines into the Xen specific

Re: [Xen-devel] [RFC PATCH v4 3/7] xen/pvh: Create a new file for Xen specific PVH code

On Wed, Feb 28, 2018 at 10:27:59AM -0800, Maran Wilson wrote: > We need to refactor PVH entry code so that support for other hypervisors > like Qemu/KVM can be added more easily. > > The first step in that direction is to create a new file that will > eventually hold the Xen specific routines. >

Re: [Xen-devel] [PATCH 8/9] drm/xen-front: Implement GEM operations

On 02/28/2018 09:46 PM, Boris Ostrovsky wrote: On 02/27/2018 01:52 AM, Oleksandr Andrushchenko wrote: On 02/27/2018 01:47 AM, Boris Ostrovsky wrote: On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote: On 02/23/2018 05:26 PM, Boris Ostrovsky wrote: On 02/21/2018 03:03 AM, Oleksandr

[Xen-devel] [xen-4.9-testing test] 120063: regressions - FAIL

flight 120063 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/120063/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 12

Re: [Xen-devel] [PATCH v2 1/2] README: require Python 2.4 or newer

On 2/28/18 1:18 PM, Doug Goldstein wrote: > change from v1: > - changed from Python 2.6 to Python 2.4 based on Not sure what happened to my mind here based on feedback on the list of folks still having environments where Python 2.4 is in use. -- Doug Goldstein signature.asc

[Xen-devel] [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

We need to refactor PVH entry code so that support for other hypervisors like Qemu/KVM can be added more easily. This patch moves the small block of code used for initializing Xen PVH virtual machines into the Xen specific file. This initialization is not going to be needed for Qemu/KVM guests.

[Xen-devel] [RFC PATCH v4 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

For certain applications it is desirable to rapidly boot a KVM virtual machine. In cases where legacy hardware and software support within the guest is not needed, Qemu should be able to boot directly into the uncompressed Linux kernel binary without the need to run firmware. There already exists

Re: [Xen-devel] [PATCH] xen-netfront: Fix hang on device removal

On 28/02/18 13:23, Jason Andryuk wrote: > A toolstack may delete the vif frontend and backend xenstore entries > while xen-netfront is in the removal code path. In that case, the > checks for xenbus_read_driver_state would return XenbusStateUnknown, and > xennet_remove would hang indefinitely.

[Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

Once hypervisors other than Xen start using the PVH entry point for starting VMs, we would like the option of being able to compile PVH entry capable kernels without enabling CONFIG_XEN and all the code that comes along with that. To allow that, we are moving the PVH code out of Xen and into files

[Xen-devel] [RFC PATCH v4 5/7] xen/pvh: Move Xen code for getting mem map via hcall out of common file

We need to refactor PVH entry code so that support for other hypervisors like Qemu/KVM can be added more easily. The original design for PVH entry in Xen guests relies on being able to obtain the memory map from the hypervisor using a hypercall. When we extend the PVH entry ABI to support other

[Xen-devel] [RFC PATCH v4 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

Sorry for the delay between this version and the last -- it was mostly due to holidays and everyone being focused on security bug mitigation issues. Here are the links to the previous email threads in case it is helpful: V3: https://lkml.org/lkml/2017/12/12/1230 V2:

[Xen-devel] [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

In order to pave the way for hypervisors other then Xen to use the PVH entry point for VMs, we need to factor the PVH entry code into Xen specific and hypervisor agnostic components. The first step in doing that, is to create a new config option for PVH entry that can be enabled independently from

[Xen-devel] [RFC PATCH v4 3/7] xen/pvh: Create a new file for Xen specific PVH code

We need to refactor PVH entry code so that support for other hypervisors like Qemu/KVM can be added more easily. The first step in that direction is to create a new file that will eventually hold the Xen specific routines. Signed-off-by: Maran Wilson --- arch/x86/pvh.c

Re: [Xen-devel] [PATCH 2/6] x86/hvm: Handle viridian MSRs via the new guest_{rd, wr}msr() infrastructure

On 28/02/18 16:40, Jan Beulich wrote: On 26.02.18 at 18:35, wrote: >> --- a/xen/arch/x86/hvm/viridian.c >> +++ b/xen/arch/x86/hvm/viridian.c >> @@ -554,13 +554,11 @@ static void update_reference_tsc(struct domain *d, >> bool_t initialize) >>

[Xen-devel] [PATCH v2 2/2] xen/tools: support Python 2 and Python 3

These changes should make it possible to support modern Pythons as well as the oldest Python 2 still supported. Signed-off-by: Doug Goldstein --- CC: Andrew Cooper CC: George Dunlap CC: Ian Jackson

[Xen-devel] [PATCH v2 1/2] README: require Python 2.4 or newer

Increase the minimum required Python to 2.4 or newer. Signed-off-by: Doug Goldstein --- CC: Andrew Cooper CC: George Dunlap CC: Ian Jackson CC: Jan Beulich CC: Konrad

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

On Wed, Feb 28, 2018 at 10:27:58AM -0800, Maran Wilson wrote: > Once hypervisors other than Xen start using the PVH entry point for > starting VMs, we would like the option of being able to compile PVH entry > capable kernels without enabling CONFIG_XEN and all the code that comes > along with

Re: [Xen-devel] [RFC PATCH v4 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 28/02/2018 19:27, Maran Wilson wrote: > Sorry for the delay between this version and the last -- it was mostly > due to holidays and everyone being focused on security bug mitigation > issues. Here are the links to the previous email threads in case it is > helpful: > > V3:

[Xen-devel] [xen-unstable-smoke test] 120102: trouble: broken/pass

flight 120102 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120102/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl broken

[Xen-devel] [xen-unstable-smoke test] 120106: regressions - trouble: blocked/broken/pass

flight 120106 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120106/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken build-armhf 5

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

On 28/02/2018 22:08, Konrad Rzeszutek Wilk wrote: > +obj-$(CONFIG_XEN_PVH) += pvh.o > +obj-$(CONFIG_XEN_PVH) += pvh-head.o > + Probably a better place for these would be arch/x86/platform/pvh/{enlighten.c,head.S}. (Just because there are no .c or .S files in arch/x86). Maybe Xen ought to be

Re: [Xen-devel] pvh+vcpus startup issue

On 28/02/18 9:35 PM, Juergen Gross wrote: On 28/02/18 09:27, Roger Pau Monné wrote: On Wed, Feb 28, 2018 at 01:34:31PM +1300, x...@randomwebstuff.com wrote: Regards, Peter http://ri.mu Startups start here. Hosting. DNS. Offsite backups. Monitoring. Email. On 27/02/18 12:42 AM, Juergen

Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

On 01/03/18 06:21, Chao Gao wrote: > On Mon, Feb 26, 2018 at 09:10:33AM -0700, Jan Beulich wrote: > On 26.02.18 at 14:11, wrote: >>> On Mon, Feb 26, 2018 at 01:26:42AM -0700, Jan Beulich wrote: >>> On 23.02.18 at 19:11, wrote: > On Wed, Dec

Re: [Xen-devel] [PATCH v4 15/20] x86emul: correctly handle CMPXCHG* comparison failures

At 06:09 -0700 on 28 Feb (1519798185), Jan Beulich wrote: > If the ->cmpxchg() hook finds a mismatch, we should deal with this the > same way as when the "manual" comparison reports a mismatch. > > This involves reverting bfce0e62c3 ("x86/emul: Drop > X86EMUL_CMPXCHG_FAILED"), albeit with

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

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

Re: [Xen-devel] [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On 28/02/18 19:27, Maran Wilson wrote: > In order to pave the way for hypervisors other then Xen to use the PVH > entry point for VMs, we need to factor the PVH entry code into Xen specific > and hypervisor agnostic components. The first step in doing that, is to > create a new config option for

Re: [Xen-devel] [PATCH 0/9] drm/xen-front: Add support for Xen PV display frontend

Hi all, just as a clarification, this patch series implements the frontend driver for the "vdispl" protocol, which was reviewed, approved and committed in xen.git back in April: https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/displif.h As Xen maintainer, if a competing

[Xen-devel] [xen-4.8-testing test] 120067: regressions - FAIL

flight 120067 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/120067/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 119771

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

flight 120107 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120107/ 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

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

On 28/02/18 22:35, Paolo Bonzini wrote: > On 28/02/2018 22:08, Konrad Rzeszutek Wilk wrote: >> +obj-$(CONFIG_XEN_PVH) += pvh.o >> +obj-$(CONFIG_XEN_PVH) += pvh-head.o >> + > > Probably a better place for these would be > arch/x86/platform/pvh/{enlighten.c,head.S}. (Just because there are no > .c

Re: [Xen-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

Hello, Konrad, Takashi, Takashi and Clemens! Could you please take a look at this series if it meets ALSA expectations on para-virtualized sound for Xen? Thank you, Oleksandr On 02/05/2018 10:24 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko

Re: [Xen-devel] [PATCH v2] pvcalls-front: 64-bit align flags

On 02/28/2018 09:05 PM, Stefano Stabellini wrote: We are using test_and_* operations on the status and flag fields of struct sock_mapping. However, these functions require the operand to be 64-bit aligned on arm64. Currently, only status is 64-bit aligned. Make status and flags explicitly

Re: [Xen-devel] [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On 28/02/18 22:07, Konrad Rzeszutek Wilk wrote: > On Wed, Feb 28, 2018 at 10:27:57AM -0800, Maran Wilson wrote: >> In order to pave the way for hypervisors other then Xen to use the PVH >> entry point for VMs, we need to factor the PVH entry code into Xen specific >> and hypervisor agnostic

Re: [Xen-devel] [PATCH v2] pvcalls-front: 64-bit align flags

On 01/03/18 03:05, Stefano Stabellini wrote: > We are using test_and_* operations on the status and flag fields of > struct sock_mapping. However, these functions require the operand to be > 64-bit aligned on arm64. Currently, only status is 64-bit aligned. > > Make status and flags explicitly

Re: [Xen-devel] [PATCH 0/9] drm/xen-front: Add support for Xen PV display frontend

On Wed, 28 Feb 2018, Julien Grall wrote: > (+ Stefano and Wei) > > Hi, > > On 02/27/2018 12:40 PM, Oleksandr Andrushchenko wrote: > > Please find some more clarifications on VirtIO use with Xen > > (I would like to thank Xen community for helping with this) > > > > 1. Possible security issues -

[Xen-devel] [PATCH v2] pvcalls-front: 64-bit align flags

We are using test_and_* operations on the status and flag fields of struct sock_mapping. However, these functions require the operand to be 64-bit aligned on arm64. Currently, only status is 64-bit aligned. Make status and flags explicitly 64-bit aligned. Signed-off-by: Stefano Stabellini

Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

On Mon, Feb 26, 2018 at 09:10:33AM -0700, Jan Beulich wrote: On 26.02.18 at 14:11, wrote: >> On Mon, Feb 26, 2018 at 01:26:42AM -0700, Jan Beulich wrote: >> On 23.02.18 at 19:11, wrote: On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao

Re: [Xen-devel] [RFC PATCH v4 5/7] xen/pvh: Move Xen code for getting mem map via hcall out of common file

On 28/02/18 19:28, Maran Wilson wrote: > We need to refactor PVH entry code so that support for other hypervisors > like Qemu/KVM can be added more easily. > > The original design for PVH entry in Xen guests relies on being able to > obtain the memory map from the hypervisor using a hypercall.

Re: [Xen-devel] [PATCH 0/5] x86: improve PDX <-> PFN and alike translations

>>> Andrew Cooper 02/28/18 6:26 PM >>> >On 28/02/18 13:51, Jan Beulich wrote: >> 1: remove page.h and processor.h inclusion from asm_defns.h >> 2: use PDEP for PTE flags insertion when available >> 3: use PDEP/PEXT for maddr/direct-map-offset conversion when available

Re: [Xen-devel] [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

On 28/02/18 19:28, Maran Wilson wrote: > The start info structure that is defined as part of the x86/HVM direct boot > ABI and used for starting Xen PVH guests would be more versatile if it also > included a way to pass information about the memory map to the guest. This > would allow KVM guests

Re: [Xen-devel] [PATCH v2 7/7] x86/build: Use new .nop directive when available

>>> Andrew Cooper 02/28/18 7:20 PM >>> >On 28/02/18 16:22, Jan Beulich wrote: > On 26.02.18 at 12:35, wrote: >>> --- a/xen/include/asm-x86/alternative-asm.h >>> +++ b/xen/include/asm-x86/alternative-asm.h >>> @@ -1,6 +1,8 @@ >>> #ifndef

Re: [Xen-devel] [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

Juergen Gross 03/01/18 8:29 AM >>> >On 28/02/18 19:28, Maran Wilson wrote: >> The start info structure that is defined as part of the x86/HVM direct boot >> ABI and used for starting Xen PVH guests would be more versatile if it also >> included a way to pass information

Re: [Xen-devel] [PATCH v2 5/7] x86/alt: Support for automatic padding calculations

>>> Andrew Cooper 02/28/18 7:02 PM >>> >On 28/02/18 16:16, Jan Beulich wrote: > On 26.02.18 at 12:35, wrote: >>> .macro ALTERNATIVE oldinstr, newinstr, feature >>> .L\@_orig_s: >>> \oldinstr >>> .L\@_orig_e: >>> +/* >>> +

Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

>>> Chao Gao 03/01/18 7:34 AM >>> >On Mon, Feb 26, 2018 at 09:10:33AM -0700, Jan Beulich wrote: >>Again - here we're talking about implementation limits, not >>bottlenecks. So in this context all I'm interested in is whether >>(and if so which) implementation limit remains. If

Re: [Xen-devel] [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

On 28/02/18 19:28, Maran Wilson wrote: > We need to refactor PVH entry code so that support for other hypervisors > like Qemu/KVM can be added more easily. > > This patch moves the small block of code used for initializing Xen PVH > virtual machines into the Xen specific file. This initialization

Re: [Xen-devel] [RFC PATCH v4 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 28/02/18 19:28, Maran Wilson wrote: > For certain applications it is desirable to rapidly boot a KVM virtual > machine. In cases where legacy hardware and software support within the > guest is not needed, Qemu should be able to boot directly into the > uncompressed Linux kernel binary without

Re: [Xen-devel] [PATCH v2 2/2] xen: events: free irqs in error condition

On Tue, Feb 27, 2018 at 05:32:53PM +, Shah, Amit wrote: > > On Di, 2018-02-27 at 17:07 +, Roger Pau Monné wrote: > > On Tue, Feb 27, 2018 at 03:55:58PM +, Amit Shah wrote: > > > > > > In case of errors in irq setup for MSI, free up the allocated irqs. > > > > > > Fixes:

Re: [Xen-devel] [RFC QEMU PATCH v4 05/10] xen-hvm: initialize fw_cfg interface

On 02/27/18 16:46 +, Anthony PERARD wrote: > On Thu, Dec 07, 2017 at 06:18:07PM +0800, Haozhong Zhang wrote: > > Xen is going to reuse QEMU to build ACPI of some devices (e.g., NFIT > > and SSDT for NVDIMM) for HVM domains. The existing QEMU ACPI build > > code requires a fw_cfg interface

[Xen-devel] [PATCH v4 03/20] x86emul: support AVX2 gather insns

Signed-off-by: Jan Beulich --- v4: Re-base. v3: Re-base. --- a/tools/tests/x86_emulator/Makefile +++ b/tools/tests/x86_emulator/Makefile @@ -13,7 +13,8 @@ run: $(TARGET) SIMD := sse sse2 sse4 avx avx2 FMA := fma4 fma -TESTCASES := blowfish $(SIMD) $(FMA) +SG := avx2-sg

[Xen-devel] [PATCH v4 01/20] x86emul: extend vbroadcasts{s, d} to AVX2

These gain register forms now. Signed-off-by: Jan Beulich --- v4: Split from main AVX2 patch. --- a/tools/tests/x86_emulator/simd.c +++ b/tools/tests/x86_emulator/simd.c @@ -70,7 +70,12 @@ static inline bool _to_bool(byte_vec_t b #if FLOAT_SIZE == 4 && defined(__SSE__) #

[Xen-devel] [PATCH v4 12/20] x86emul: support SWAPGS

Signed-off-by: Jan Beulich --- v4: Add best effort unwind attempt to ->write_segment() failure path. v3: New. --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -5054,6 +5054,28 @@ x86_emulate( goto done;

[Xen-devel] [PATCH v4 15/20] x86emul: correctly handle CMPXCHG* comparison failures

If the ->cmpxchg() hook finds a mismatch, we should deal with this the same way as when the "manual" comparison reports a mismatch. This involves reverting bfce0e62c3 ("x86/emul: Drop X86EMUL_CMPXCHG_FAILED"), albeit with X86EMUL_CMPXCHG_FAILED now becoming a value distinct from X86EMUL_RETRY.

[Xen-devel] [PATCH v4 1/2][XTF] add FPU/SIMD register state test

Add tests to verify that - FPU insns leave correct (guest) values in FIP/FDP/FOP/FCS/FDS (at the example for FSTPS), - FPU insns writing memory don't update FPU register state when the write faults (at the example of FISTPS), - VCVTPS2PH (once implemented in the emulator) doesn't update MXCSR

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

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

[Xen-devel] [PATCH 0/5] x86: improve PDX <-> PFN and alike translations

1: remove page.h and processor.h inclusion from asm_defns.h 2: use PDEP for PTE flags insertion when available 3: use PDEP/PEXT for maddr/direct-map-offset conversion when available 4: use PDEP/PEXT for PFN/PDX conversion when available 5: use MOV for PFN/PDX conversion when possible

Re: [Xen-devel] [PATCH v3] x86/mm: Suppresses vm_events caused by page-walks

>>> On 28.02.18 at 14:41, wrote: On 28.02.18 at 14:25, wrote: >> --- a/xen/arch/x86/mm/mem_access.c >> +++ b/xen/arch/x86/mm/mem_access.c >> @@ -137,6 +137,23 @@ bool p2m_mem_access_emulate_check(struct vcpu *v, >> return violation; >> } >>

[Xen-devel] [PATCH 3/5] x86: use PDEP/PEXT for maddr/direct-map-offset conversion when available

Both replace 6 instructions by a single one, further reducing code size, cache, and TLB footprint (in particular on systems supporting BMI2). Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -393,11 +393,26 @@ void __init arch_init_memory(void)

Re: [Xen-devel] [PATCH v2 2/5] xen: sched/credit1: make vcpu_migration_delay per-cpupool

On 02/28/2018 02:23 PM, George Dunlap wrote: > On 02/23/2018 04:41 PM, Dario Faggioli wrote: >> Right now, vCPU migration delay is controlled by >> the vcpu_migration_delay boot parameter. This means >> the same value will always be used for every instance >> of Credit1, in any cpupool that will

Re: [Xen-devel] [PATCH v2 3/5] tools: libxl/xl: allow to get/set Credit1's vcpu_migration_delay

On 02/23/2018 04:41 PM, Dario Faggioli wrote: > Make it possible to get and set a (Credit1) scheduler's > vCPU migration delay via the SCHEDOP sysctl, from both > libxl and xl (no change needed in libxc). > > Signed-off-by: Dario Faggioli > --- > Cc: Ian Jackson

Re: [Xen-devel] [PATCH 4/5] x86: use PDEP/PEXT for PFN/PDX conversion when available

I'm sorry for the bogus "Re:" in the original subject; not sure how that happened. Jan >>> On 28.02.18 at 14:58, wrote: > Both replace 6 instructions by a single one, further reducing code size, > cache, and TLB footprint (in particular on systems supporting BMI2). > >

[Xen-devel] [PATCH v4 04/20] x86emul: support XOP insns

Signed-off-by: Jan Beulich Acked-by: Andrew Cooper --- v4: Re-base. --- a/.gitignore +++ b/.gitignore @@ -243,6 +243,7 @@ tools/tests/x86_emulator/sse*.[ch] tools/tests/x86_emulator/test_x86_emulator tools/tests/x86_emulator/x86_emulate

[Xen-devel] [PATCH v4 05/20] x86emul: support 3DNow! insns

Yes, recent AMD CPUs don't support them anymore, but I think we should nevertheless cope. Signed-off-by: Jan Beulich --- v4: Fix PI2FW table entry. Add comment to _3dnow{,_ext}_table[] describing the encoding. v3: Re-base. --- a/.gitignore +++ b/.gitignore @@ -236,6

[Xen-devel] [PATCH v4 16/20] x86emul: add read-modify-write hook

In order to correctly emulate read-modify-write insns, especially LOCKed ones, we should not issue reads and writes separately. Use a new hook to combine both, and don't uniformly read the memory destination anymore. Instead, DstMem opcodes without Mov now need to have done so in their respective

Re: [Xen-devel] [PATCH v3] x86/mm: Suppresses vm_events caused by page-walks

>>> On 28.02.18 at 14:25, wrote: > --- a/xen/arch/x86/mm/mem_access.c > +++ b/xen/arch/x86/mm/mem_access.c > @@ -137,6 +137,23 @@ bool p2m_mem_access_emulate_check(struct vcpu *v, > return violation; > } > > +static void p2m_set_ad_bits(struct vcpu *v, paddr_t ga)

[Xen-devel] [PATCH 5/5] x86: use MOV for PFN/PDX conversion when possible

... and (of course) also maddr / direct-map-offset ones. Most x86 systems don't actually require the use of PDX compression. Now that we have patching for the conversion code in place anyway, extend it to use simple MOV when possible. Introduce a new pseudo-CPU-feature to key the patching off of.

Re: [Xen-devel] [PATCH 4/5] x86: use PDEP/PEXT for PFN/PDX conversion when available

Both replace 6 instructions by a single one, further reducing code size, cache, and TLB footprint (in particular on systems supporting BMI2). Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -394,6 +394,7 @@ void __init arch_init_memory(void)

[Xen-devel] [PATCH v4 02/20] x86emul: support most remaining AVX2 insns

--- a/tools/tests/x86_emulator/Makefile +++ b/tools/tests/x86_emulator/Makefile @@ -11,9 +11,9 @@ all: $(TARGET) run: $(TARGET) ./$(TARGET) -SIMD := sse sse2 sse4 avx +SIMD := sse sse2 sse4 avx avx2 FMA := fma4 fma -TESTCASES := blowfish $(SIMD) sse2-avx sse4-avx $(FMA) +TESTCASES :=

[Xen-devel] [PATCH v4 07/20] x86: move and rename XSTATE_*

Signed-off-by: Jan Beulich --- v4: New, split off from later patch. --- a/xen/arch/x86/cpuid.c +++ b/xen/arch/x86/cpuid.c @@ -122,42 +122,42 @@ static void recalculate_xstate(struct cp if ( p->basic.avx ) { -xstates |= XSTATE_YMM; +xstates |=

[Xen-devel] [PATCH v4 06/20] x86emul: place test blobs in executable section

This allows the section contents to be disassembled without going through any extra hoops, simplifying the analysis of problems in test and/or emulation code. The blobs being emitted as (r/o) data means we need to accept an assembler warning here (about the differing section attributes).

[Xen-devel] [PATCH v4 10/20] x86emul: make all FPU emulation use the stub

While this means quite some reduction of (source) code, the main purpose is to no longer have exceptions raised from other than stubs. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper --- v4: Add (redundant) modrm_reg masking to

[Xen-devel] [PATCH v4 11/20] x86/HVM: eliminate custom #MF/#XM handling

Use the generic stub exception handling instead. Signed-off-by: Jan Beulich Reviewed-by: Paul Durrant Acked-by: Andrew Cooper --- v4: Re-base. v3: Re-base. v2: Re-base. --- a/tools/tests/x86_emulator/x86-emulate.c +++

Re: [Xen-devel] [RFC PATCH 08/49] ARM: VGIC: move max_vcpus VGIC limit to struct arch_domain

Hi, On 02/28/2018 12:32 PM, Andre Przywara wrote: Hi, On 09/02/18 19:27, Julien Grall wrote: Hi, On 02/09/2018 02:38 PM, Andre Przywara wrote: The VGIC model used for a domain (GICv2 or GICv3) determines the maximum number of VCPUs for that guest, as GICv2 can only handle 8 processors. In

[Xen-devel] [PATCH v4 09/20] x86emul: adjust_bnd() should check XCR0

Experimentally MPX instructions have been confirmed to behave as NOPs unless both related XCR0 bits are set to 1. By implication branches then also don't clear BNDn. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper --- v4: Re-base over XSTATE_*

Re: [Xen-devel] [PATCH v3] build: remove shim related targets

On Wed, Feb 28, 2018 at 05:29:06AM -0700, Jan Beulich wrote: > >>> On 28.02.18 at 12:47, wrote: > > On Wed, Feb 28, 2018 at 04:02:53AM -0700, Jan Beulich wrote: > >> >>> On 21.02.18 at 13:22, wrote: > >> > --- a/tools/firmware/Makefile > >> > +++

[Xen-devel] [PATCH v4 18/20] x86/HVM: make use of new read-modify-write emulator hook

..., at least as far as currently possible, i.e. when a mapping can be obtained. Signed-off-by: Jan Beulich Reviewed-by: Paul Durrant Reviewed-by: Andrew Cooper --- v4: bool_t -> bool. v3: New. ---

[Xen-devel] [PATCH v4 17/20] x86/HVM: do actual CMPXCHG in hvmemul_cmpxchg()

..., at least as far as currently possible, i.e. when a mapping can be obtained. Signed-off-by: Jan Beulich Reviewed-by: Paul Durrant --- v4: Add ASSERT_UNREACHABLE() to hvmemul_cmpxchg()'s switch(). v3: New. --- a/xen/arch/x86/hvm/emulate.c +++

[Xen-devel] [PATCH v3] x86/mm: Suppresses vm_events caused by page-walks

This patch is adding a way to enable/disable inguest pagefault events. It introduces the xc_monitor_inguest_pagefault function and adds the inguest_pagefault_disabled in the monitor structure. This is needed by the introspection so it will only get gla faults and not get spammed with other faults.

Re: [Xen-devel] [PATCH v3] build: remove shim related targets

>>> On 28.02.18 at 14:02, wrote: > On Wed, Feb 28, 2018 at 05:29:06AM -0700, Jan Beulich wrote: >> >>> On 28.02.18 at 12:47, wrote: >> > On Wed, Feb 28, 2018 at 04:02:53AM -0700, Jan Beulich wrote: >> >> >>> On 21.02.18 at 13:22,

[Xen-devel] [PATCH 1/6] xen/domain: Reduce the quantity of initialisation for system domains

* System domains don't need watchdog initialisation or iomem/irq rangesets, and will not plausibly be a xenstore or hardware domain. * The idle domain doesn't need scheduler initialisation (and in particular, removing this path allows for substantial scheduler cleanup), and isn't liable

[Xen-devel] Ping: [PATCH 1/2] x86: improve MSR_SHADOW_GS accesses

>>> On 06.12.17 at 17:37, wrote: > Instead of using RDMSR/WRMSR, on fsgsbase-capable systems use a double > SWAPGS combined with RDGSBASE/WRGSBASE. This halves execution time for > a shadow GS update alone on my Haswell (and we have indications of > good performance improvements by this on

[Xen-devel] [PATCH v4 08/20] x86emul: abstract out XCRn accesses

Use hooks, just like done for other special purpose registers. This includes moving XCR0 checks from hvmemul_get_fpu() to the emulator itself as well as adding support for XGETBV emulation. For now fuzzer reads will obtain the real values (minus the fuzzing of the hook pointer itself).

[Xen-devel] [PATCH v4 13/20] x86emul: tell cmpxchg hook whether LOCK is in effect

This is necessary for the hook to correctly perform the operation. Signed-off-by: Jan Beulich Reviewed-by: Paul Durrant Reviewed-by: Andrew Cooper --- v3: New. --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c +++

[Xen-devel] [PATCH v4 14/20] x86/PV: convert page table emulation code from paddr_t to intpte_t

It's dealing with PTEs after all. Signed-off-by: Jan Beulich Acked-by: Andrew Cooper --- v4: New, split off from later patch. --- a/xen/arch/x86/pv/ro-page-fault.c +++ b/xen/arch/x86/pv/ro-page-fault.c @@ -65,7 +65,7 @@ static int

Re: [Xen-devel] [PATCH v4 07/20] x86: move and rename XSTATE_*

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 28 February 2018 13:02 > To: xen-devel > Cc: Andrew Cooper ; Paul Durrant > ; George Dunlap > Subject:

[Xen-devel] [PATCH v4 0/2][XTF] FPU test improvements

1: add FPU/SIMD register state test 2: extend FPU exception tests Signed-off-by: Jan Beulich --- v4: Just re-basing, no other feedback was received. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH v8 09/11] vpci/msi: add MSI handlers

>>> On 23.01.18 at 16:07, wrote: > Add handlers for the MSI control, address, data and mask fields in > order to detect accesses to them and setup the interrupts as requested > by the guest. > > Note that the pending register is not trapped, and the guest can > freely

[Xen-devel] [PATCH 2/6] xen/credit2: Move repl_timer into struct csched2_dom

For exactly the same reason as 418ae6021d. Having a separate allocation is unnecessary and wasteful. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Dario Faggioli --- xen/common/sched_credit2.c | 20

[Xen-devel] [PATCH 3/6] xen/sched: Improvements to the {alloc, free}_domdata() interfaces

The main purpose of this change is for the subsequent cleanup it enables, but it stands on its own merits. In principle, these hooks are optional, but the SCHED_OP() default aliases a memory allocation failure, which causes arinc653 to play the dangerous game of passing its priv pointer back, and

Re: [Xen-devel] [PATCH v2 2/5] xen: sched/credit1: make vcpu_migration_delay per-cpupool

On 02/23/2018 04:41 PM, Dario Faggioli wrote: > Right now, vCPU migration delay is controlled by > the vcpu_migration_delay boot parameter. This means > the same value will always be used for every instance > of Credit1, in any cpupool that will be created. > > Also, in order to get and set such

Re: [Xen-devel] [PATCH v8 11/11] vpci/msix: add MSI-X handlers

>>> On 23.01.18 at 16:07, wrote: > +void vpci_msix_arch_print(const struct vpci_msix *msix) > +{ > +unsigned int i; > + > +for ( i = 0; i < msix->max_entries; i++ ) > +{ > +const struct vpci_msix_entry *entry = >entries[i]; > + > +printk("%6u

[Xen-devel] [PATCH v4 07/20] x86: move and rename XSTATE_*

Signed-off-by: Jan Beulich --- v4: New, split off from later patch. --- a/xen/arch/x86/cpuid.c +++ b/xen/arch/x86/cpuid.c @@ -122,42 +122,42 @@ static void recalculate_xstate(struct cp if ( p->basic.avx ) { -xstates |= XSTATE_YMM; +xstates |=

[Xen-devel] [PATCH v4 20/20] x86/shadow: fold sh_x86_emulate_{write, cmpxchg}() into their only callers

The functions have a single caller only and are now guest paging type independent (except for the tracing part), so have no need to exist as standalone ones, let alone multiple times. Replace the two prior hooks with just a single one for dealing with tracing. Signed-off-by: Jan Beulich

  1   2   >