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

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

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

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

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

On Thu, 15 Feb 2018 17:02:35 +0100 Yessine Daoud wrote: > Hello, > >I tried to debug the issue and this what I found: >the HVM boot takes some time at the following section >(qemu/pc-bios/optionrom/linuxboot.S) >/* Load kernel and initrd */

[Xen-devel] [xen-unstable test] 119217: regressions - trouble: blocked/broken/fail/pass

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

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-freebsd10-amd64

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

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with Linus' tree

On Fri, 16 Feb 2018, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the xen-tip tree got a conflict in: > > drivers/xen/pvcalls-front.c > > between commit: > > a9a08845e9ac ("vfs: do bulk POLL* -> EPOLL* replacement") > > from Linus' tree and commit: > > 1e7dbff356e5

[Xen-devel] [xen-4.7-testing bisection] complete build-i386

branch xen-4.7-testing xenbranch xen-4.7-testing job build-i386 testid xen-build Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced:

[Xen-devel] linux-next: manual merge of the xen-tip tree with Linus' tree

Hi all, Today's linux-next merge of the xen-tip tree got a conflict in: drivers/xen/pvcalls-front.c between commit: a9a08845e9ac ("vfs: do bulk POLL* -> EPOLL* replacement") from Linus' tree and commit: 1e7dbff356e5 ("pvcalls-front: introduce a per sock_mapping refcount") from the

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

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

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

Hi all, This series changes the initialization of two virtual registers to make sure they match the value of the underlying physical cpu. It also disables cpus different from the boot cpu, unless a newly introduced command line option is specified. In that case, it explains how to setup the

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

On big.LITTLE systems not all cores have the same midr. Instead of initializing the vpidr to the boot cpu midr, set it to the value of the midr of the pcpu where the vcpu will run. This way, assuming that the vcpu has been created with the right pcpu affinity, the guest will be able to read the

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

Update the documentation of the hmp-unsafe option to explain how to use it safely, together with the right cpu affinity setting, on big.LITTLE systems. Also update the warning message to point users to the docs. Signed-off-by: Stefano Stabellini CC: jbeul...@suse.com CC:

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

On big.LITTLE systems not all cores have the same ACTLR. Instead of reading ACTLR and setting v->arch.actlr in vcpu_initialise, which is run always on pcpu 0, do it later on the same pcpu where the vcpu will run. This way, assuming that the vcpu has been created with the right pcpu affinity, the

[Xen-devel] [PATCH 1/4] xen/arm: Park CPUs with a MIDR different from the boot CPU.

From: Julien Grall From: Julien Grall Xen does not properly support big.LITTLE platform. All vCPUs of a guest will always have the MIDR of the boot CPU (see arch_domain_create). At best the guest may see unreliable performance (vCPU switching between

Re: [Xen-devel] [PATCH v3] xen/arm: Park CPUs with a MIDR different from the boot CPU.

On Thu, 15 Feb 2018, Julien Grall wrote: > Xen does not properly support big.LITTLE platform. All vCPUs of a guest > will always have the MIDR of the boot CPU (see arch_domain_create). > At best the guest may see unreliable performance (vCPU switching between > big and LITTLE), at worst the guest

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

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

[Xen-devel] Minutes of the Xen ARM community call Tuesday 13th February 5PM UTC

Hi all, These are the minutes of the meeting we had earlier this week. Thank you all for attending! Cheers, Stefano Attendees: Stefano Stabellini, Julien Grall (ARM), Artem Mygaiev (EPAM), Mirela Simonovic (Aggios), Davorin Mista (Aggios), Christopher Clark, Andrii Anisov (EPAM), Rich

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

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

[Xen-devel] [xen-4.7-testing bisection] complete build-i386-xsm

branch xen-4.7-testing xenbranch xen-4.7-testing job build-i386-xsm testid xen-build Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced:

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

On 02/15/2018 08:57 PM, Andrew Cooper wrote: > On 15/02/18 16:25, Roger Pau Monne wrote: >> There a bunch of bits in CR4 that should be allowed to be set directly >> by the guest without requiring Xen intervention, currently this is >> already done by passing through guest writes into the CR4 used

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

On 02/15/2018 06:50 PM, Jan Beulich wrote: On 09.02.18 at 12:01, wrote: >> @@ -563,13 +563,19 @@ void svm_update_guest_cr(struct vcpu *v, unsigned int >> cr) >> case 3: >> vmcb_set_cr3(vmcb, v->arch.hvm_vcpu.hw_cr[3]); >> if (

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

flight 119295 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/119295/ 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] vmx/hap: optimize CR4 trapping

On 15/02/18 16:25, Roger Pau Monne wrote: > There a bunch of bits in CR4 that should be allowed to be set directly > by the guest without requiring Xen intervention, currently this is > already done by passing through guest writes into the CR4 used when > running in non-root mode, but taking an

Re: [Xen-devel] [PATCH v3 0/2] pvcalls-front improvements

On 14/02/18 19:26, Stefano Stabellini wrote: > Hi all, > > this small series introduces a per socket refcount to increase the > efficiency on socket release operations, and makes releasing passive > sockets safe. > > Cheers, > > Stefano > > > Changes in v3: > - remove pointless initializers >

Re: [Xen-devel] PVH Dom0 ACPI tables

>>> On 15.02.18 at 17:59, wrote: > On Thu, Feb 15, 2018 at 03:05:03AM -0700, Jan Beulich wrote: >> >>> On 14.02.18 at 11:30, wrote: >> > Tables related to devices in use by Xen (or not available to Dom0) >> > >> > HPET, DMAR, IVRS, WAET, CSRT, BOOT,

Re: [Xen-devel] PVH Dom0 ACPI tables

On Thu, Feb 15, 2018 at 03:05:03AM -0700, Jan Beulich wrote: > >>> On 14.02.18 at 11:30, wrote: > > Hello, > > > > After the comments on the ACPI whitelisting patch for PVH Dom0 I've > > decided to post the list of ACPI tables that I've used to create the > > current

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

On 15/02/18 16:03, Jan Beulich wrote: > The stub is within reach from the .text section, so there's no point > using an indirect call here. This has the added benefit of there no > longer being two sufficiently different approaches, breaking one of > which people may not even notice. > >

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

>>> On 09.02.18 at 12:01, wrote: > @@ -563,13 +563,19 @@ void svm_update_guest_cr(struct vcpu *v, unsigned int > cr) > case 3: > vmcb_set_cr3(vmcb, v->arch.hvm_vcpu.hw_cr[3]); > if ( !nestedhvm_enabled(v->domain) ) > -

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

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

[Xen-devel] [linux-arm-xen test] 119195: tolerable all pass - PUSHED

flight 119195 linux-arm-xen real [real] http://logs.test-lab.xenproject.org/osstest/logs/119195/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 116992 test-armhf-armhf-libvirt-xsm 14

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

The stub is within reach from the .text section, so there's no point using an indirect call here. This has the added benefit of there no longer being two sufficiently different approaches, breaking one of which people may not even notice. Signed-off-by: Jan Beulich ---

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

Hello, I tried to debug the issue and this what I found: the HVM boot takes some time at the following section (qemu/pc-bios/optionrom/linuxboot.S) /* Load kernel and initrd */ read_fw_blob_addr32_edi(FW_CFG_INITRD) (ramdisk about 3M takes ~~7.s) read_fw_blob_addr32(FW_CFG_KERNEL) (vmlinuz about

Re: [Xen-devel] [PATCH RFC 0/4] Use INVPCID to flush global mappings

On 15/02/18 13:10, Wei Liu wrote: > I wrote these patches sometime ago to explore PCID and INVPCID. I haven't > thought through whether how to use both in Xen yet. But seeing Juergen laid > out > his thought on PCID and INVPCID I think some of the patches can be useful. > > I had done some

[Xen-devel] [PATCH v3] xen/arm: Park CPUs with a MIDR different from the boot CPU.

Xen does not properly support big.LITTLE platform. All vCPUs of a guest will always have the MIDR of the boot CPU (see arch_domain_create). At best the guest may see unreliable performance (vCPU switching between big and LITTLE), at worst the guest will become unreliable or insecure. This is

Re: [Xen-devel] [PATCH v3 10/17] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

Julien, On 15.02.18 17:02, Julien Grall wrote: Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1. Signed-off-by: Julien Grall Reviewed-by: Volodymyr Babchuk --- Changes in v3: - Add the missing call to smc

Re: [Xen-devel] [PATCH v3 02/17] xen/arm: vsmc: Implement SMCCC 1.1

Hi Julien, On 15.02.18 17:02, Julien Grall wrote: The new SMC Calling Convention (v1.1) allows for a reduced overhead when calling into the firmware, and provides a new feature discovery mechanism. See "Firmware interfaces for mitigating CVE-2017-5715" ARM DEN 00070A. Signed-off-by: Julien

Re: [Xen-devel] [PATCH v2] xen/arm: Park CPUs with a MIDR different from the boot CPU.

Hi Jan, On 15/02/18 09:03, Jan Beulich wrote: On 14.02.18 at 15:17, wrote: --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -1000,6 +1000,16 @@ supported only when compiled with XSM on x86. Control Xens use of the APEI Hardware

[Xen-devel] [PATCH v3 09/17] xen/arm: smccc: Implement SMCCC v1.1 inline primitive

One of the major improvement of SMCCC v1.1 is that it only clobbers the first 4 registers, both on 32 and 64bit. This means that it becomes very easy to provide an inline version of the SMC call primitive, and avoid performing a function call to stash the registers that woudl otherwise be

[Xen-devel] [PATCH v3 13/17] xen/arm: psci: Consolidate PSCI version print

Xen is printing the same way the PSCI version for 0.1, 0.2 and later. The only different is the former is hardcoded. Furthermore PSCI is now used for other things than SMP bring up. So only print the PSCI version in psci_init. Signed-off-by: Julien Grall Reviewed-by:

[Xen-devel] [PATCH v3 03/17] xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support

SMCCC 1.1 offers firmware-based CPU workarounds. In particular, SMCCC_ARCH_WORKAROUND_1 provides BP hardening for variant 2 of XSA-254 (CVE-2017-5715). If the hypervisor has some mitigation for this issue, report that we deal with it using SMCCC_ARCH_WORKAROUND_1, as we apply the hypervisor

[Xen-devel] [PATCH v3 05/17] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_1

The function SMCCC_ARCH_WORKAROUND_1 will be called by the guest for hardening the branch predictor. So we want the handling to be as fast as possible. As the mitigation is applied on every guest exit, we can check for the call before saving all the context and return very early. For now, only

[Xen-devel] [PATCH v3 17/17] xen/arm: vpsci: Rework the logic to start AArch32 vCPU in Thumb mode

32-bit domain is able to select the instruction (ARM vs Thumb) to use when boot a new vCPU via CPU_ON. This is indicated via bit[0] of the entry point address (see "T32 support" in PSCI v1.1 DEN0022D). bit[0] must be cleared when setting the PC. At the moment, Xen is setting the CPSR.T but never

[Xen-devel] [PATCH v3 06/17] xen/arm64: Print a per-CPU message with the BP hardening method used

This will make easier to know whether BP hardening has been enabled for a CPU and which method is used. Signed-off-by: Julien Grall Reviewed-by: Volodymyr Babcuk --- Changes in v3: - Add Volodymyr's reviewed-by Changes in v2:

[Xen-devel] [PATCH v3 12/17] xen/arm: vpsci: Remove parameter 'ver' from do_common_cpu

Currently, the behavior of do_common_cpu will slightly change depending on the PSCI version passed in parameter. Looking at the code, more the specific 0.2 behavior could move out of the function or adapted for 0.1: - x0/r0 can be updated on PSCI 0.1 because general purpose registers are

[Xen-devel] [PATCH v3 11/17] xen/arm64: Kill PSCI_GET_VERSION as a variant-2 workaround

Now that we've standardised on SMCCC v1.1 to perform the branch prediction invalidation, let's drop the previous band-aid. If vendors haven't updated their firmware to do SMCCC 1.1, they haven't updated PSCI either, so we don't loose anything. This is aligned with the Linux commit 3a0a397ff5ff.

[Xen-devel] [PATCH v3 10/17] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1. Signed-off-by: Julien Grall --- Changes in v3: - Add the missing call to smc #0. Changes in v2: - Patch added --- xen/arch/arm/arm64/bpi.S| 13 +

[Xen-devel] [PATCH v3 14/17] xen/arm: psci: Prefix with static any functions not exported

A bunch of PSCI functions are not prefixed with static despite no one is using them outside the file and the prototype is not available in psci.h. Signed-off-by: Julien Grall Reviewed-by: Volodymyr Babchuk --- Changes in v2: -

[Xen-devel] [PATCH v3 04/17] xen/arm: Adapt smccc.h to be able to use it in assembly code

Signed-off-by: Julien Grall Reviewed-by: Volodymyr Babchuk --- Changes in v2: - Add Volodymyr's reviewed-by --- xen/include/asm-arm/smccc.h | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git

[Xen-devel] [PATCH v3 02/17] xen/arm: vsmc: Implement SMCCC 1.1

The new SMC Calling Convention (v1.1) allows for a reduced overhead when calling into the firmware, and provides a new feature discovery mechanism. See "Firmware interfaces for mitigating CVE-2017-5715" ARM DEN 00070A. Signed-off-by: Julien Grall --- Changes in v3:

[Xen-devel] [PATCH v3 16/17] xen/arm: vpsci: Introduce and use PSCI_INVALID_ADDRESS

PSCI 1.0 added the error return PSCI_INVALID_ADDRESS. It is used to indicate the entry point address is known to be invalid. In Xen case, this error could be returned when a 64-bit vCPU is using a Thumb entry address. For PSCI 0.1 implementation, return PSCI_INVALID_PARAMETERS instead.

[Xen-devel] [PATCH v3 08/17] xen/arm: psci: Detect SMCCC version

PSCI 1.0 and later allows the SMCCC version to be (indirectly) probed via PSCI_FEATURES. If the PSCI_FEATURES does not exist (PSCI 0.2 or earlier) and the function return an error, then we considered SMCCC 1.0 is implemented. Signed-off-by: Julien Grall --- Changes in

[Xen-devel] [PATCH v3 15/17] xen/arm: vpsci: Update the return type for MIGRATE_INFO_TYPE

From the specification, the PSCI call MIGRATE_INFO_TYPE will return an int32_t. Update the function return type to match it. Signed-off-by: Julien Grall Cc: mirela.simono...@aggios.com --- Changes in v3: - Patch added --- xen/arch/arm/vpsci.c | 2 +- 1 file

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

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

[Xen-devel] [xen-4.6-testing test] 119227: tolerable FAIL - PUSHED

flight 119227 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/119227/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-2 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 119187 pass in 119227

Re: [Xen-devel] [PATCH v4 0/4] hvm/svm: Enable vm events for SVM

On 15/02/18 13:05, Razvan Cojocaru wrote: > On 02/15/2018 02:36 PM, Andrew Cooper wrote: >> One thing I note however is that patch 2 and 3 both turn on intercepts >> and have no way of turning them back off.  This appears to be consistent >> with the Intel side of things, but it is suboptimal for

Re: [Xen-devel] [PATCH 30/30] xen: use the BYTE-based definitions

Hi Philippe, On Thu, Feb 15, 2018 at 09:23:52AM -0300, Philippe Mathieu-Daudé wrote: > > Can I add your R-b tag once fixed? Respin will be: > > +xenstore_write_int(dom, "memory/target", ram_size / K_BYTE); > +xenstore_write_int(vm, "memory", ram_size / M_BYTE); > +

Re: [Xen-devel] [PATCH RFC 3/4] x86: add invpcid.h

>>> On 15.02.18 at 13:35, wrote: > On Thu, Feb 15, 2018 at 05:34:26AM -0700, Jan Beulich wrote: >> >>> On 15.02.18 at 13:10, wrote: >> > Provide the functions needed for different modes. >> >> Do we really need all of these? Let's not have dead code sit

Re: [Xen-devel] [PATCH v4 0/4] hvm/svm: Enable vm events for SVM

On 02/15/2018 05:22 AM, Alexandru Isaila wrote: > Hi all, > > This series provides a skeleton for enabling vm_events on SVM. For the > first step, the MSR, CR, Breakpoint and GuestRequest have been tested > and added to the capabilities list. > Reviewed-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH v4 0/4] hvm/svm: Enable vm events for SVM

On 02/15/2018 02:36 PM, Andrew Cooper wrote: > One thing I note however is that patch 2 and 3 both turn on intercepts > and have no way of turning them back off.  This appears to be consistent > with the Intel side of things, but it is suboptimal for the guest when > an introspection agent

[Xen-devel] [PATCH] x86/xpti: avoid copying L4 page table contents when possible

For mitigation of Meltdown the current L4 page table is copied to the cpu local root page table each time a 64 bit pv guest is entered. Copying can be avoided in cases where the guest L4 page table hasn't been modified while running the hypervisor, e.g. when handling interrupts or any hypercall

Re: [Xen-devel] [PATCH v4 0/4] hvm/svm: Enable vm events for SVM

On 15/02/18 10:22, Alexandru Isaila wrote: > Hi all, > > This series provides a skeleton for enabling vm_events on SVM. For the > first step, the MSR, CR, Breakpoint and GuestRequest have been tested > and added to the capabilities list. Ok - this series is looking much clearer now.  Thanks.

Re: [Xen-devel] [PATCH RFC 3/4] x86: add invpcid.h

On Thu, Feb 15, 2018 at 05:34:26AM -0700, Jan Beulich wrote: > >>> On 15.02.18 at 13:10, wrote: > > Provide the functions needed for different modes. > > Do we really need all of these? Let's not have dead code sit around > and risk it becoming stale. > They will be needed

Re: [Xen-devel] [PATCH RFC 3/4] x86: add invpcid.h

>>> On 15.02.18 at 13:10, wrote: > Provide the functions needed for different modes. Do we really need all of these? Let's not have dead code sit around and risk it becoming stale. Jan ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH RFC 1/4] x86: introduce cpu_has_invpcid

>>> On 15.02.18 at 13:10, wrote: > --- a/xen/include/asm-x86/cpufeature.h > +++ b/xen/include/asm-x86/cpufeature.h > @@ -93,6 +93,7 @@ > #define cpu_has_avx2boot_cpu_has(X86_FEATURE_AVX2) > #define cpu_has_smepboot_cpu_has(X86_FEATURE_SMEP) >

Re: [Xen-devel] [PATCH RFC 3/4] x86: add invpcid.h

On 15/02/18 12:24, Wei Liu wrote: > On Thu, Feb 15, 2018 at 12:15:56PM +, Andrew Cooper wrote: >> On 15/02/18 12:10, Wei Liu wrote: >>> Provide the functions needed for different modes. >>> >>> Signed-off-by: Wei Liu >>> --- >>> xen/include/asm-x86/invpcid.h | 61 >>>

Re: [Xen-devel] [PATCH RFC 3/4] x86: add invpcid.h

On Thu, Feb 15, 2018 at 12:15:56PM +, Andrew Cooper wrote: > On 15/02/18 12:10, Wei Liu wrote: > > Provide the functions needed for different modes. > > > > Signed-off-by: Wei Liu > > --- > > xen/include/asm-x86/invpcid.h | 61 > >

Re: [Xen-devel] [PATCH 30/30] xen: use the BYTE-based definitions

On 02/15/2018 08:00 AM, Alan Robinson wrote: > Hi Philippe, > > On Thu, Feb 15, 2018 at 01:29:00AM -0300, Philippe Mathieu-Daudé wrote: >> From: Philippe Mathieu-Daudé >> Subject: [Xen-devel] [PATCH 30/30] xen: use the BYTE-based definitions >> List-Id: Xen developer discussion

Re: [Xen-devel] [PATCH RFC 3/4] x86: add invpcid.h

On 15/02/18 12:10, Wei Liu wrote: > Provide the functions needed for different modes. > > Signed-off-by: Wei Liu > --- > xen/include/asm-x86/invpcid.h | 61 > +++ > 1 file changed, 61 insertions(+) > create mode 100644

[Xen-devel] [PATCH RFC 4/4] x86: use invpcid to do global flush

Signed-off-by: Wei Liu --- xen/arch/x86/flushtlb.c | 22 ++ 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c index 8a7a76b8ff..e4ea4f3297 100644 --- a/xen/arch/x86/flushtlb.c +++

[Xen-devel] [PATCH RFC 0/4] Use INVPCID to flush global mappings

I wrote these patches sometime ago to explore PCID and INVPCID. I haven't thought through whether how to use both in Xen yet. But seeing Juergen laid out his thought on PCID and INVPCID I think some of the patches can be useful. I had done some benchmark on the speed in one of my older branch by

[Xen-devel] [PATCH RFC 2/4] x86: report if PCID and INVPCID are supported

Signed-off-by: Wei Liu --- xen/arch/x86/setup.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index ac530ece2c..89e42865a4 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1701,6 +1701,13 @@ void __init

[Xen-devel] [PATCH RFC 3/4] x86: add invpcid.h

Provide the functions needed for different modes. Signed-off-by: Wei Liu --- xen/include/asm-x86/invpcid.h | 61 +++ 1 file changed, 61 insertions(+) create mode 100644 xen/include/asm-x86/invpcid.h diff --git

[Xen-devel] [PATCH RFC 1/4] x86: introduce cpu_has_invpcid

Signed-off-by: Wei Liu --- xen/include/asm-x86/cpufeature.h | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h index 55b696ed07..db8072279d 100644 --- a/xen/include/asm-x86/cpufeature.h +++

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemuu-win10-i386

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

Re: [Xen-devel] [PATCH 0/8] xen: add pvh guest support

Hi Juergen, Sorry for huge delay. It looks that I am recovering slowly and probably I will have more time for reviews. On Wed, Nov 29, 2017 at 02:46:42PM +0100, Juergen Gross wrote: > This patch series adds support for booting Linux as PVH guest. > > Similar to i386/xen and x86_64/xen platforms

Re: [Xen-devel] [PATCH 8/8] xenpvh: add support to configure

On Wed, Nov 29, 2017 at 02:46:50PM +0100, Juergen Gross wrote: > Support platform i386/xenpvh in configure. > > Signed-off-by: Juergen Gross Reviewed-by: Daniel Kiper Daniel ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH 7/8] xenpvh: support grub-install for xenpvh

On Wed, Nov 29, 2017 at 02:46:49PM +0100, Juergen Gross wrote: > Add xenpvh support to grub-install. > > Signed-off-by: Juergen Gross Reviewed-by: Daniel Kiper Daniel ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH 6/8] xenpvh: support building a standalone image

On Wed, Nov 29, 2017 at 02:46:48PM +0100, Juergen Gross wrote: > Suppor mkimage for xenpvh. > > Signed-off-by: Juergen Gross > --- > include/grub/util/mkimage.h | 3 ++- > util/grub-mkimage32.c | 1 + > util/grub-mkimage64.c | 1 + > util/grub-mkimagexx.c |

Re: [Xen-devel] [PATCH 5/8] xenpvh: add build runes for grub-core

On Wed, Nov 29, 2017 at 02:46:47PM +0100, Juergen Gross wrote: > Add the modifications to the build system needed to build a xenpvh > grub. > > Signed-off-by: Juergen Gross Reviewed-by: Daniel Kiper Daniel

Re: [Xen-devel] [PATCH 4/8] xen: add xen pvh guest support to grub-core

On Wed, Nov 29, 2017 at 02:46:46PM +0100, Juergen Gross wrote: > Add all the grub-core code needed for Xen PVH guest support. This > includes: > > - The new PVH entry point of grub > - PVH specific initialization code > - machine specific header files > - modifications in Xen specific code to work

Re: [Xen-devel] [PATCH 3/8] xen: carve out grant tab initialization into dedicated function

On Wed, Nov 29, 2017 at 02:46:45PM +0100, Juergen Gross wrote: > Initialize the grant tab in a dedicated function. This will enable > using it for PVH guests, too. > > Signed-off-by: Juergen Gross > --- > grub-core/kern/xen/init.c | 35 +-- > 1

Re: [Xen-devel] [PATCH v2 02/15] xen/arm: vpsci: Add support for PSCI 1.1

On 14/02/18 19:14, Mirela Simonovic wrote: Hi Julien, Hi, On 02/13/2018 12:44 AM, Julien Grall wrote: On 12/02/2018 23:16, Mirela Simonovic wrote: Hi Julien, Hi, On 02/12/2018 10:41 PM, Julien Grall wrote: On 12/02/2018 20:12, Mirela Simonovic wrote: Hi Julien, Hi Mirela,

[Xen-devel] [PATCH] xsm:schedop: introduce vcpuinfo permissions verification

From: Andrii Anisov Introduce per-vcpu scheduler operations permission verification. As long as Xvcpuinfo are in fact scheduler configuration manipulations there is no need to introduce specific access vectors. Signed-off-by: Andrii Anisov ---

Re: [Xen-devel] Hangs after /etc/init.d/xencommons start

On Tue, Feb 13, 2018 at 04:19:27PM -0800, ls00...@yahoo.com wrote: > Hi all: > I am using arm64 ( hikey) to test for xen. > After struggling for two week, I was able to build and install everything > on the target, xen and dom0 kernel boots up ok. > However, when I try to use “xl

[Xen-devel] [PATCH v4 1/3] hvm/svm: Enable Breakpoint events

This commit implements the breakpoint events for svm. At the moment, the Breakpoint vmexit is not forwarded to the monitor layer. This patch adds the hvm_monitor_debug call to the VMEXIT_EXCEPTION_BP. Also, the Software Breakpoint cap is moved from the Intel arch to the common part of the code.

[Xen-devel] [PATCH v4 2/3] hvm/svm: Enable MSR events

At this moment there is no function to enable msr interception on svm. This patch implements this function and moves the mov to msr monitor event form the Intel arch side to the common capabilities. Signed-off-by: Alexandru Isaila Acked-by: Tamas K Lengyel

[Xen-devel] [PATCH v4 3/3] hvm/svm: Enable CR events

The CR_INTERCEPT_CR3_WRITE intercept is out of the vmcb->_cr_intercepts so the AMD arch can't intercept CR events. This patch implements the CR intercept by adding the flag on a write_ctrlreg event. The monitor write ctrlreg event is moved from the Intel side to the common capabilities side. We

[Xen-devel] [PATCH v4 0/4] hvm/svm: Enable vm events for SVM

Hi all, This series provides a skeleton for enabling vm_events on SVM. For the first step, the MSR, CR, Breakpoint and GuestRequest have been tested and added to the capabilities list. Cheers, Alexandru Isaila ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

>>> On 14.02.18 at 17:23, wrote: > The current XPTI implementation isolates the directmap (and therefore a lot > of > guest data), but a large quantity of CPU0's state (including its stack) > remains visible. > > Furthermore, an attacker able to read .text is in a

Re: [Xen-devel] PVH Dom0 ACPI tables

>>> On 14.02.18 at 11:30, wrote: > Hello, > > After the comments on the ACPI whitelisting patch for PVH Dom0 I've > decided to post the list of ACPI tables that I've used to create the > current whitelist, together with other tables that I've not yet added. > > Allowed

Re: [Xen-devel] [PATCH 22/30] hw/display: use the BYTE-based definitions

On Thu, Feb 15, 2018 at 01:28:52AM -0300, Philippe Mathieu-Daudé wrote: > It ease code review, unit is explicit. Reviewed-by: Gerd Hoffmann ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH v4 2/7] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

>>> On 14.02.18 at 18:02, wrote: > 2018-02-14 16:37 GMT+08:00 Jan Beulich : > On 14.02.18 at 08:15, wrote: >>> 2018-02-13 23:26 GMT+08:00 Jan Beulich : >>> On 13.02.18 at 16:15,

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

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

Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events

On Mi, 2018-02-14 at 19:11 +, Andrew Cooper wrote: > On 14/02/18 18:22, Andrew Cooper wrote: > > > > On 14/02/18 16:10, Alexandru Stefan ISAILA wrote: > > > > > > On Lu, 2018-02-12 at 15:54 +, Andrew Cooper wrote: > > > > > > > > On 12/02/18 15:08, Alexandru Isaila wrote: > > > > > > > > >