[Xen-devel] [PATCH 3/4] x86emul: correct handling of FPU insns faulting on memory write

When an FPU instruction with a memory destination fails during the memory write, it should not affect FPU register state. Due to the way we emulate FPU (and SIMD) instructions, we can only guarantee this by - backing out changes to the FPU register state in such a case or - doing a descriptor read

[Xen-devel] [PATCH 2/4] x86emul: centralize put_fpu() invocations

..., splitting parts of it into check_*() macros. This is in preparation of making ->put_fpu() do further adjustments to register state. (Some of the check_xmm() invocations could be avoided, as in some of the cases no insns handled there can actually raise #XM, but I think we're better off

[Xen-devel] [PATCH 1/4] x86emul: fold exit paths

Move "cannot_emulate" and make it go through the common (error) exit path. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -7762,7 +7762,9 @@ x86_emulate( } default: -goto

Re: [Xen-devel] Xen 4.6.5 released

>>> On 13.03.17 at 11:29, wrote: > On 13/03/17 09:24, Jan Beulich wrote: > On 10.03.17 at 18:22, wrote: >>> On 08.03.2017 13:54, Jan Beulich wrote: All, I am pleased to announce the release of Xen 4.6.5. This is

Re: [Xen-devel] [PATCH v1 1/3] x86/vvmx: add mov-ss blocking check to vmentry

On 13/03/17 10:51, Sergey Dyasli wrote: > Intel SDM states that if there is a current VMCS and there is MOV-SS > blocking, VMFailValid occurs and control passes to the next instruction. > > Implement such behaviour for nested vmlaunch and vmresume. > > Signed-off-by: Sergey Dyasli

[Xen-devel] [PATCH 15/18] xen/arm: Introduce a helper to synchronize SError

We may have to isolate the SError between the context switch of 2 vCPUs or may have to prevent slipping hypervisor SError to guest. So we need a helper to synchronize SError before context switching or returning to guest. This function will be used by the later patches in this series, we use "#if

[Xen-devel] [PATCH 13/18] xen/arm: Replace do_trap_guest_serror with new helpers

We have introduced two helpers to handle the guest/hyp SErrors: do_trap_guest_serror and do_trap_guest_hyp_serror. These handlers can take the role of do_trap_guest_serror and reduce the assembly code in the same time. So we use these two helpers to replace it and drop it now. Signed-off-by: Wei

[Xen-devel] [PATCH 18/18] xen/arm: Handle guest external abort as guest SError

The guest generated external data/instruction aborts can be treated as guest SErrors. We already have a handler to handle the SErrors, so we can reuse this handler to handle guest external aborts. Signed-off-by: Wei Chen --- xen/arch/arm/traps.c | 14 ++ 1 file

[Xen-devel] [PATCH 17/18] xen/arm: Prevent slipping hypervisor SError to guest

If there is a pending SError while we're returning from trap. If the SError handle option is "DIVERSE", we have to prevent slipping this hypervisor SError to guest. So we have to use the dsb/isb to guarantee that the pending hypervisor SError would be caught in hypervisor before return to guest.

[Xen-devel] [PATCH 12/18] xen/arm: Introduce new helpers to handle guest/hyp SErrors

Currently, ARM32 and ARM64 has different SError exception handlers. These handlers include lots of code to check SError handle options and code to distinguish guest-generated SErrors from hypervisor SErrors. The new helpers: do_trap_guest_serror and do_trap_hyp_serror are wrappers of

[Xen-devel] [PATCH 09/18] xen/arm64: Use alternative to skip the check of pending serrors

We have provided an option to administrator to determine how to handle the SErrors. In order to skip the check of pending SError, in conventional way, we have to read the option every time before we try to check the pending SError. This will add overhead to check the option at every trap. The

[Xen-devel] [PATCH 16/18] xen/arm: Isolate the SError between the context switch of 2 vCPUs

If there is a pending SError while we are doing context switch, if the SError handle option is "FORWARD", We have to guranatee this serror to be caught by current vCPU, otherwise it will be caught by next vCPU and be forwarded to this wrong vCPU. We don't want to export serror_op accessing to

[Xen-devel] [PATCH 14/18] xen/arm: Unmask the Abort/SError bit in the exception entries

Currently, we masked the Abort/SError bit in Xen exception entries. So Xen could not capture any Abort/SError while it's running. Now, Xen has the ability to handle the Abort/SError, we should unmask the Abort/SError bit by default to let Xen capture Abort/SError while it's running. But in order

[Xen-devel] [PATCH 0/4] x86emul: FPU handling corrections

1: fold exit paths 2: centralize put_fpu() invocations 3: correct handling of FPU insns faulting on memory write 4: correct FPU code/data pointers and opcode handling XTF: add FPU/SIMD register state test Signed-off-by: Jan Beulich

[Xen-devel] [PATCH 11/18] xen/arm: Move macro VABORT_GEN_BY_GUEST to common header

We want to move part of SErrors checking code from hyp_error assembly code to a function. This new function will use this macro to distinguish the guest SErrors from hypervisor SErrors. So we have to move this macro to common header. Signed-off-by: Wei Chen ---

[Xen-devel] [PATCH 06/18] xen/arm: Introduce a virtual abort injection helper

When guest triggers async aborts, in most platform, such aborts will be routed to hypervisor. But we don't want the hypervisor to handle such aborts, so we have to route such aborts back to the guest. This helper is using the HCR_EL2.VSE (HCR.VA for aarch32) bit to route such aborts back to the

[Xen-devel] [PATCH 03/18] xen/arm: Avoid setting/clearing HCR_RW at every context switch

The HCR_EL2 flags for 64-bit and 32-bit domains are different. But when we initialized the HCR_EL2 for vcpu0 of Dom0 and all vcpus of DomU in vcpu_initialise, we didn't know the domain's address size information. We had to use compatible flags to initialize HCR_EL2, and set HCR_RW for 64-bit

[Xen-devel] [PATCH 10/18] xen/arm32: Use cpu_hwcaps to skip the check of pending serrors

We have provided an option to administrator to determine how to handle the SErrors. In order to skip the check of pending SError, in conventional way, we have to read the option every time before we try to check the pending SError. Currently, we haven't export the option to other source file.

[Xen-devel] [PATCH 08/18] xen/arm: Introduce a initcall to update cpu_hwcaps by serror_op

In the later patches of this series, we want to use the alternative patching framework to avoid checking serror_op in every entries. So we define a new cpu feature "SKIP_CHECK_PENDING_VSERROR" for serror_op. When serror_op is not equal to SERROR_DIVERSE, this feature will be set to cpu_hwcaps.

[Xen-devel] [PATCH 07/18] xen/arm: Introduce a command line parameter for SErrors/Aborts

In order to distinguish guest-generated SErrors from hypervisor-generated SErrors. We have to place SError checking code in every EL1 -> EL2 paths. That will be an overhead on entries caused by dsb/isb. But not all platforms want to categorize the SErrors. For example, a host that is running with

Re: [Xen-devel] [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu, 9 Mar 2017 13:54:00 +0100 Michal Hocko wrote: [...] > > It's major regression if you remove auto online in kernels that > > run on top of x86 kvm/vmware hypervisors, making API cleanups > > while breaking useful functionality doesn't make sense. > > > > I would ACK

[Xen-devel] [PATCH 05/18] xen/arm: Save ESR_EL2 to avoid using mismatched value in syndrome check

Xen will do exception syndrome check while some types of exception take place in EL2. The syndrome check code read the ESR_EL2 register directly, but in some situation this register maybe overridden by nested exception. For example, if we re-enable IRQ before reading ESR_EL2 which means Xen will

[Xen-devel] [PATCH 01/18] xen/arm: Introduce a helper to get default HCR_EL2 flags

We want to add HCR_EL2 register to Xen context switch. And each copy of HCR_EL2 in vcpu structure will be initialized with the same set of trap flags as the HCR_EL2 register. We introduce a helper here to represent these flags to be reused easily. Signed-off-by: Wei Chen ---

[Xen-devel] [PATCH 02/18] xen/arm: Restore HCR_EL2 register

Different domains may have different HCR_EL2 flags. For example, the 64-bit domain needs HCR_RW flag but the 32-bit does not need it. So we give each domain a default HCR_EL2 value and save it in the VCPU's context. HCR_EL2 register has only one bit can be updated automatically without explicit

[Xen-devel] [PATCH 00/18] Provide a command line option to choose how to handle SErrors

From XSA-201 (see [1]), we know that, a guest could trigger SErrors when accessing memory mapped HW in a non-conventional way. In the patches for XSA-201, we crash the guest when we captured such asynchronous aborts to avoid data corruption. In order to distinguish guest-generated SErrors from

[Xen-devel] [PATCH 04/18] xen/arm: Save HCR_EL2 when a guest took the SError

The HCR_EL2.VSE (HCR.VA for aarch32) bit can be used to generate a virtual abort to guest. The HCR_EL2.VSE bit has a peculiar feature of getting cleared when the guest has taken the abort (this is the only bit that behaves as such in HCR_EL2 register). This means that if we set the HCR_EL2.VSE

Re: [Xen-devel] [GSoC 2017] Rust bindings for libxl

On Mon, Mar 13, 2017 at 10:47:08AM +, Wei Liu wrote: > Hello Saurav > > On Mon, Mar 06, 2017 at 03:50:37PM +, Saurav Sachidanand wrote: > > Hello, > > > > I'm Saurav Sachidanand, and I'm a CS sophomore studying in India. For > > more than year I've been programming in Rust and have

[Xen-devel] [PATCH v1 3/3] x86/vvmx: add a shadow vmcs check to vmlaunch

Intel SDM states that if the current VMCS is a shadow VMCS, VMFailInvalid occurs and control passes to the next instruction. Implement such behaviour for nested vmlaunch. Signed-off-by: Sergey Dyasli --- xen/arch/x86/hvm/vmx/vvmx.c | 7 +++ 1 file changed, 7

[Xen-devel] [PATCH v1 0/3] x86/vvmx: fixes for mov-ss and shadow vmcs handling

This series includes 2 more checks for nested vmentry and a fix for handling a nested shadow vmcs. Sergey Dyasli (3): x86/vvmx: add mov-ss blocking check to vmentry x86/vvmx: correct nested shadow VMCS handling x86/vvmx: add a shadow vmcs check to vmlaunch xen/arch/x86/hvm/vmx/vvmx.c

[Xen-devel] [PATCH v1 2/3] x86/vvmx: correct nested shadow VMCS handling

Currently xen always sets the shadow VMCS-indicator bit on nested vmptrld and always clears it on nested vmclear. This behavior is wrong when the guest loads a shadow VMCS: shadow bit will be lost on nested vmclear. Fix this by checking if the guest has provided a shadow VMCS. Signed-off-by:

[Xen-devel] [PATCH v1 1/3] x86/vvmx: add mov-ss blocking check to vmentry

Intel SDM states that if there is a current VMCS and there is MOV-SS blocking, VMFailValid occurs and control passes to the next instruction. Implement such behaviour for nested vmlaunch and vmresume. Signed-off-by: Sergey Dyasli --- xen/arch/x86/hvm/vmx/vvmx.c

Re: [Xen-devel] Xen 4.6.5 released

On 13.03.2017 11:29, Andrew Cooper wrote: > On 13/03/17 09:24, Jan Beulich wrote: > On 10.03.17 at 18:22, wrote: >>> On 08.03.2017 13:54, Jan Beulich wrote: All, I am pleased to announce the release of Xen 4.6.5. This is available immediately

Re: [Xen-devel] [GSoC 2017] Rust bindings for libxl

Hello Saurav On Mon, Mar 06, 2017 at 03:50:37PM +, Saurav Sachidanand wrote: > Hello, > > I'm Saurav Sachidanand, and I'm a CS sophomore studying in India. For > more than year I've been programming in Rust and have published some > personal projects in it (few involving the Rust-C FFI) and

Re: [Xen-devel] WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Mon 13-03-17 11:31:10, Igor Mammedov wrote: > On Fri, 10 Mar 2017 14:58:07 +0100 [...] > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009] > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x0010-0x3fff] > > [0.00] ACPI: SRAT: Node 1 PXM 1 [mem

[Xen-devel] [PATCH] tools/Rules.mk: libxlutil should use $(XEN_XLUTIL)

A typo was made in 7a6de259f. Currently libxlutil lives in the same directory as libxl, fixing this issue causes no functional change. Signed-off-by: Wei Liu --- tools/Rules.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/Rules.mk

Re: [Xen-devel] WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Fri, 10 Mar 2017 14:58:07 +0100 Michal Hocko wrote: > Let's CC people touching this logic. A short summary is that onlining > memory via udev is currently unusable for online_movable because blocks > are added from lower addresses while movable blocks are allowed from >

Re: [Xen-devel] Xen 4.6.5 released

On 13/03/17 09:24, Jan Beulich wrote: On 10.03.17 at 18:22, wrote: >> On 08.03.2017 13:54, Jan Beulich wrote: >>> All, >>> >>> I am pleased to announce the release of Xen 4.6.5. This is >>> available immediately from its git repository >>>

[Xen-devel] [ovmf test] 106629: regressions - FAIL

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

Re: [Xen-devel] [PATCH v2 21/21] x86/xen: rename some PV-only functions in smp_pv.c

On 02/03/17 18:53, Vitaly Kuznetsov wrote: > After code split between PV and HVM some functions in xen_smp_ops have > xen_pv_ prefix and some only xen_ which makes them look like they're > common for both PV and HVM while they're not. Rename all the rest to > have xen_pv_ prefix. > >

Re: [Xen-devel] [PATCH v2 20/21] x86/xen: enable PVHVM-only builds

On 02/03/17 18:53, Vitaly Kuznetsov wrote: > Now everything is in place and we can move PV-only code under > CONFIG_XEN_PV. CONFIG_XEN_PV_SMP is created to support the change. > > Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross Juergen

Re: [Xen-devel] [PATCH v2 19/21] xen: create xen_create/destroy_contiguous_region() stubs for PVHVM only builds

On 02/03/17 18:53, Vitaly Kuznetsov wrote: > xen_create_contiguous_region()/xen_create_contiguous_region() are PV-only, > they both contain xen_feature(XENFEAT_auto_translated_physmap) check and > bail in the very beginning. > > Signed-off-by: Vitaly Kuznetsov Reviewed-by:

Re: [Xen-devel] [PATCH v2 18/21] xen/balloon: decorate PV-only parts with #ifdef CONFIG_XEN_PV

On 02/03/17 18:53, Vitaly Kuznetsov wrote: > Balloon driver uses several PV-only concepts (xen_start_info, > xen_extra_mem,..) and it seems the simpliest solution to make HVM-only > build happy is to decorate these parts with #ifdefs. > > Signed-off-by: Vitaly Kuznetsov

Re: [Xen-devel] [PATCH v2 17/21] x86/xen: create stubs for HVM-only builds in page.h

On 02/03/17 18:53, Vitaly Kuznetsov wrote: > __pfn_to_mfn() is only used from PV code (mmu_pv.c, p2m.c) and from > page.h where all functions calling it check for > xen_feature(XENFEAT_auto_translated_physmap) first so we can replace > it with any stub to make build happy. > >

Re: [Xen-devel] [PATCH v2 16/21] x86/xen: define startup_xen for XEN PV only

On 02/03/17 18:53, Vitaly Kuznetsov wrote: > startup_xen references PV-only code, decorate it with #ifdef CONFIG_XEN_PV > to make PV-free builds possible. > > Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross Juergen

Re: [Xen-devel] [PATCH v2 13/21] x86/xen: split off mmu_pv.c

On 02/03/17 18:53, Vitaly Kuznetsov wrote: > Basically, mmu.c is renamed to mmu_pv.c and some code moved out to common > mmu.c. > > Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross Juergen ___

Re: [Xen-devel] [PATCH v2 12/21] x86/xen: split off mmu_hvm.c

On 02/03/17 18:53, Vitaly Kuznetsov wrote: > Move PVHVM related code to mmu_hvm.c. > > Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH v2 11/21] x86/xen: split off smp_pv.c

On 02/03/17 18:53, Vitaly Kuznetsov wrote: > Basically, smp.c is renamed to smp_pv.c and some code moved out to common > smp.c. struct xen_common_irq delcaration ended up in smp.h. > > Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross Juergen

Re: [Xen-devel] Xen 4.6.5 released

>>> On 10.03.17 at 18:22, wrote: > On 08.03.2017 13:54, Jan Beulich wrote: >> All, >> >> I am pleased to announce the release of Xen 4.6.5. This is >> available immediately from its git repository >>

Re: [Xen-devel] [OSSTEST PATCH] ts-xtf-run: Understand ./xtf-runner returning CRASH

On Tue, Mar 07, 2017 at 03:26:52PM +, Andrew Cooper wrote: > ./xtf-runner wants to distinguish between a clean and unclean exits of the > test. OSSTest doesn't care, so map unclean exit to failure. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu

Re: [Xen-devel] WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Fri 10-03-17 13:00:37, Reza Arbab wrote: > On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote: > >OK, so while I was playing with this setup some more I probably got why > >this is done this way. All new memblocks are added to the zone Normal > >where they are accounted as spanned but

Re: [Xen-devel] WTH is going on with memory hotplug sysf interface

On Fri 10-03-17 12:39:27, Yasuaki Ishimatsu wrote: > On 03/10/2017 08:58 AM, Michal Hocko wrote: [...] > >OK so I did with -m 2G,slots=4,maxmem=4G -numa node,mem=1G -numa node,mem=1G > >which generated > >[...] > >[0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009] > >[

Re: [Xen-devel] [PATCH v2] xen: don't save/restore the physmap on VM save/restore

> -Original Message- > From: Igor Druzhinin > Sent: 10 March 2017 20:07 > To: sstabell...@kernel.org; Anthony Perard > Cc: Paul Durrant ; qemu-de...@nongnu.org; xen- > de...@lists.xenproject.org; Igor Druzhinin

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

flight 106628 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/106628/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 5 xen-install fail REGR. vs. 106608 Regressions which are

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

flight 106625 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/106625/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 11 guest-start fail REGR. vs. 59254

Re: [Xen-devel] [PATCH v2 10/21] x86/xen: split off smp_hvm.c

On 02/03/17 18:53, Vitaly Kuznetsov wrote: > Move PVHVM related code to smp_hvm.c. Drop 'static' qualifier from > xen_smp_send_reschedule(), xen_smp_send_call_function_ipi(), > xen_smp_send_call_function_single_ipi(), these functions will be moved to > common smp code when smp_pv.c is split. > >

Re: [Xen-devel] [PATCH v2 09/21] x86/xen: split xen_cpu_die()

On 02/03/17 18:53, Vitaly Kuznetsov wrote: > Split xen_cpu_die() into xen_pv_cpu_die() and xen_hvm_cpu_die() to support > further splitting of smp.c. > > Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross Juergen

Re: [Xen-devel] [PATCH v2 08/21] x86/xen: split xen_smp_prepare_boot_cpu()

On 02/03/17 18:53, Vitaly Kuznetsov wrote: > Split xen_smp_prepare_boot_cpu() into xen_pv_smp_prepare_boot_cpu() and > xen_hvm_smp_prepare_boot_cpu() to support further splitting of smp.c. > > Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross

Re: [Xen-devel] [PATCH v2 07/21] x86/xen: split xen_smp_intr_init()/xen_smp_intr_free()

On 02/03/17 18:53, Vitaly Kuznetsov wrote: > xen_smp_intr_init() and xen_smp_intr_free() have PV-specific code and as > a praparatory change to splitting smp.c we need to split these fucntions. > Create xen_smp_intr_init_pv()/xen_smp_intr_free_pv(). > > Signed-off-by: Vitaly Kuznetsov

Re: [Xen-devel] [PATCH net v4] xen-netback: fix race condition on XenBus disconnect

From: Igor Druzhinin Date: Fri, 10 Mar 2017 21:36:22 + > In some cases during XenBus disconnect event handling and subsequent > queue resource release there may be some TX handlers active on > other processors. Use RCU in order to synchronize with them. > >

[Xen-devel] [Question] About the behavior of HLT in VMX guest mode

Hi guys, I'm confusing about the behavior of HLT instruction in VMX guest mode. I set "hlt exiting" bit to 0 in VMCS, and the vcpu didn't vmexit when execute HLT as expected. However, I used powertop/cpupower on host to watch the pcpu's c-states, it seems that the pcpu didn't enter C1/C1E state

<    1   2