[Xen-devel] [qemu-mainline test] 119749: trouble: blocked/broken/fail/pass

flight 119749 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/119749/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsmbroken

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

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

flight 119748 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/119748/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amdbroken in 119698

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

flight 119713 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/119713/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 119451

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

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

Re: [Xen-devel] AD bits in traditional PV mode

On 21/02/2018 00:42, Andres Lagar Cavilla wrote: > Hello everyone, > > I was thinking of the traditional Xen PV mode in which page table > pages are write protected from guest meddling and PTE > modifications are audited by the hypervisor (ptwr_emulated_update() > these days, still?). Something

[Xen-devel] [xen-4.6-testing test] 119720: regressions - trouble: broken/fail/pass

flight 119720 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/119720/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 broken

Re: [Xen-devel] [PATCH v2] xen/arm: vgic: Make sure the number of SPIs is a multiple of 32

On Fri, 16 Feb 2018, Julien Grall wrote: > The vGIC relies on having a pending_irq available for every IRQs > described in the ranks. As each rank describes 32 interrupts, we need to > make sure the number of SPIs is a multiple of 32. > > Reported-by: Jeff Kubascik

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

On Thu, 15 Feb 2018, Julien Grall wrote: > 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. >

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

On Thu, 15 Feb 2018, Julien Grall wrote: > 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

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

On Thu, 15 Feb 2018, Julien Grall wrote: > >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 Reviewed-by: Stefano Stabellini

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

On Thu, 15 Feb 2018, Julien Grall wrote: > 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

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

On Thu, 15 Feb 2018, Julien Grall wrote: > 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

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

On Thu, 15 Feb 2018, Julien Grall wrote: > 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:

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

On Thu, 15 Feb 2018, Julien Grall wrote: > 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. > >

[Xen-devel] AD bits in traditional PV mode

Hello everyone, I was thinking of the traditional Xen PV mode in which page table pages are write protected from guest meddling and PTE modifications are audited by the hypervisor (ptwr_emulated_update() these days, still?). Without software shadows or paging to e.g. an EPT, native PV loads the

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

On Thu, 15 Feb 2018, Julien Grall wrote: > 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

Re: [Xen-devel] [PATCH v3 01/17] xen/arm: vpsci: Add support for PSCI 1.1

On Thu, 15 Feb 2018, Julien Grall wrote: > At the moment, Xen provides virtual PSCI interface compliant with 0.1 > and 0.2. Since them, the specification has been updated and the latest > version is 1.1 (see ARM DEN 0022D). > > >From an implementation point of view, only PSCI_FEATURES is

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

On Thu, 15 Feb 2018, Julien Grall wrote: > 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 > --- >

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

On Thu, 15 Feb 2018, Julien Grall wrote: > 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

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

On Thu, 15 Feb 2018, Julien Grall wrote: > 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:

[Xen-devel] [PATCH 2/2] x86/svm: enable pause filtering threshold

If available, enable the pause filtering threshold feature. See the previous commit for more information. Signed-off-by: Brian Woods --- xen/arch/x86/hvm/svm/svm.c | 1 + xen/arch/x86/hvm/svm/vmcb.c | 3 +++ 2 files changed, 4 insertions(+) diff --git

[Xen-devel] [PATCH 1/2] x86/svm: add support for pause filtering threshold

Add support for enabling the pause filtering threshold feature. This causes the pause filtering count to reset if there's pause filtering threshold cycles or greater between pauses. See AMD APM Vol 2 Section 15.14.4 for more details. The values of the pause filtering count and threshold were

[Xen-devel] [PATCH 0/2] x86/svm: add pause filtering threshold for SVM

This patch series adds support and enablement of the pause filtering threshold. Once there's pause filtering threshold amount of cycles between pauses, the pause filtering counter resets to what was in the VMCB. This allows the pause filtering count to "reset" between pauses and keeps the guset

Re: [Xen-devel] [PATCH v2 5/6] xen/arm: read cacheline size when needed

On Tue, 20 Feb 2018, Julien Grall wrote: > On 20/02/2018 21:16, Julien Grall wrote: > > Hi, > > > > On 20/02/2018 21:03, Stefano Stabellini wrote: > >> On Tue, 20 Feb 2018, Julien Grall wrote: > >>> On 19/02/18 21:58, Stefano Stabellini wrote: > +    mrc   CP32(r6, CSSELR_EL1) > >>> >

Re: [Xen-devel] [PATCH] mm: don't defer struct page initialization for Xen pv guests

On Mon, 19 Feb 2018 02:45:27 +0800 kbuild test robot wrote: > [auto build test ERROR on mmotm/master] > [also build test ERROR on v4.16-rc1 next-20180216] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: >

[Xen-devel] [PATCH v4 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set. Reported-by: Andrew Cooper Signed-off-by: Brian Woods --- xen/arch/x86/hvm/svm/nestedsvm.c| 66 + xen/arch/x86/hvm/svm/svm.c

Re: [Xen-devel] [PATCH v2 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

On Tue, Feb 20, 2018 at 05:09:24PM -0500, Boris Ostrovsky wrote: > That's possibly because you needed an SVM maintainer ACK. > > I think Jan was waiting for decision on how to present the ASSERT. From > the 3 options I slightly more prefer > > ASSERT(nestedhvm_enabled(v->domain) ||

Re: [Xen-devel] [PATCH v2 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

On 02/20/2018 05:00 PM, Brian Woods wrote: > I've seen patch 1 and 3 are in but this one isn't. Any status on it? > That's possibly because you needed an SVM maintainer ACK. I think Jan was waiting for decision on how to present the ASSERT. From the 3 options I slightly more prefer

Re: [Xen-devel] [PATCH v2 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

I've seen patch 1 and 3 are in but this one isn't. Any status on it? -- Brian Woods ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 5/6] xen/arm: read cacheline size when needed

On 20/02/2018 21:16, Julien Grall wrote: > Hi, > > On 20/02/2018 21:03, Stefano Stabellini wrote: >> On Tue, 20 Feb 2018, Julien Grall wrote: >>> On 19/02/18 21:58, Stefano Stabellini wrote: +    mrc   CP32(r6, CSSELR_EL1) >>> >>> The size of the cache is read using CSSIDR_EL1. But it

Re: [Xen-devel] [PATCH v2 5/6] xen/arm: read cacheline size when needed

Hi, On 20/02/2018 21:03, Stefano Stabellini wrote: On Tue, 20 Feb 2018, Julien Grall wrote: On 19/02/18 21:58, Stefano Stabellini wrote: +mrc CP32(r6, CSSELR_EL1) The size of the cache is read using CSSIDR_EL1. But it looks like the way we get the cache line size in Xen is

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

flight 119752 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/119752/ 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 5/6] xen/arm: read cacheline size when needed

On Tue, 20 Feb 2018, Julien Grall wrote: > Hi Stefano, > > On 19/02/18 21:58, Stefano Stabellini wrote: > > On big.LITTLE systems the cacheline size might differ between big and > > LITTLE cores. Instead of reading the cacheline size once at boot, > > read it as needed from the system registers.

Re: [Xen-devel] [PATCH v2 4/6] xen/arm: make vpidr per vcpu

On Tue, 20 Feb 2018, Julien Grall wrote: > Hi Stefano, > > On 19/02/18 21:58, Stefano Stabellini wrote: > > On big.LITTLE systems not all cores have the same midr. Instead of > > storing only one vpidr per domain, make it per vcpu and initialize it to > > the value of the midr of the pcpu where

Re: [Xen-devel] [PATCH v1 2/2] hvm/svm: Implement CPUID events

On Tue, Feb 20, 2018 at 3:37 AM, Alexandru Stefan ISAILA wrote: > On Lu, 2018-02-19 at 08:25 -0700, Tamas K Lengyel wrote: >> On Mon, Feb 19, 2018 at 6:07 AM, Alexandru Isaila >> wrote: >> > >> > At this moment the CPUID events for the AMD

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

flight 119687 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/119687/ 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

Re: [Xen-devel] [PATCH 5/5] x86: Rework MSR_TSC_AUX handling from scratch.

On 20/02/18 17:35, Roger Pau Monné wrote: > On Tue, Feb 20, 2018 at 11:58:43AM +, Andrew Cooper wrote: >> There are many problems with MSR_TSC_AUX handling. >> >> To being with, the RDPID instruction reads MSR_TSC_AUX, but it is only the >> RDTSCP feature which enumerates the MSR. Therefore,

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

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

[Xen-devel] [seabios test] 119698: regressions - trouble: broken/fail/pass

flight 119698 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/119698/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-ws16-amd64 17

Re: [Xen-devel] [PATCH 5/5] x86: Rework MSR_TSC_AUX handling from scratch.

On 20/02/18 17:03, Wei Liu wrote: > On Tue, Feb 20, 2018 at 11:58:43AM +, Andrew Cooper wrote: >> There are many problems with MSR_TSC_AUX handling. >> >> To being with, the RDPID instruction reads MSR_TSC_AUX, but it is only the > ^ > begin > >> RDTSCP feature which enumerates the

Re: [Xen-devel] [PATCH 5/5] x86: Rework MSR_TSC_AUX handling from scratch.

On Tue, Feb 20, 2018 at 11:58:43AM +, Andrew Cooper wrote: > There are many problems with MSR_TSC_AUX handling. > > To being with, the RDPID instruction reads MSR_TSC_AUX, but it is only the > RDTSCP feature which enumerates the MSR. Therefore, RDPID functionally > depends on RDTSCP. > >

Re: [Xen-devel] [PATCH 5/5] x86: Rework MSR_TSC_AUX handling from scratch.

On Tue, Feb 20, 2018 at 11:58:43AM +, Andrew Cooper wrote: > There are many problems with MSR_TSC_AUX handling. > > To being with, the RDPID instruction reads MSR_TSC_AUX, but it is only the ^ begin > RDTSCP feature which enumerates the MSR. Therefore, RDPID functionally > depends

Re: [Xen-devel] [PATCH 4/5] x86/pv: Remove deferred RDTSC{, P} handling in pv_emulate_privileged_op()

On 20/02/18 16:28, Roger Pau Monné wrote: > On Tue, Feb 20, 2018 at 11:58:42AM +, Andrew Cooper wrote: >> The handling of RDTSCP for PV guests has been broken (AFAICT forever). >> >> To start with, RDTSCP is hidden from PV guests so the MSR_TSC_AUX path should >> be unreachable. However, this

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

On Tue, 20 Feb 2018, Julien Grall wrote: > Hi Stefano, > > On 19/02/18 21:58, Stefano Stabellini wrote: > > diff --git a/docs/misc/xen-command-line.markdown > > b/docs/misc/xen-command-line.markdown > > index 2184cb9..8997904 100644 > > --- a/docs/misc/xen-command-line.markdown > > +++

Re: [Xen-devel] [PATCH 4/5] x86/pv: Remove deferred RDTSC{, P} handling in pv_emulate_privileged_op()

On Tue, Feb 20, 2018 at 11:58:42AM +, Andrew Cooper wrote: > The handling of RDTSCP for PV guests has been broken (AFAICT forever). > > To start with, RDTSCP is hidden from PV guests so the MSR_TSC_AUX path should > be unreachable. However, this appears to be a "feature" of

[Xen-devel] [libvirt test] 119702: tolerable all pass - PUSHED

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

Re: [Xen-devel] [PATCH 3/5] x86/time: Rework pv_soft_rdtsc() to aid further cleanup

On 20/02/18 16:04, Roger Pau Monné wrote: > On Tue, Feb 20, 2018 at 11:58:41AM +, Andrew Cooper wrote: >> Having pv_soft_rdtsc() emulate all parts of an rdtscp is awkward, and gets in >> the way of some intended cleanup. >> >> * Drop the rdtscp parameter and always make the caller responsible

Re: [Xen-devel] [PATCH 4/5] x86/pv: Remove deferred RDTSC{, P} handling in pv_emulate_privileged_op()

On Tue, Feb 20, 2018 at 11:58:42AM +, Andrew Cooper wrote: > The handling of RDTSCP for PV guests has been broken (AFAICT forever). > > To start with, RDTSCP is hidden from PV guests so the MSR_TSC_AUX path should > be unreachable. However, this appears to be a "feature" of

Re: [Xen-devel] [PATCH 3/5] x86/time: Rework pv_soft_rdtsc() to aid further cleanup

On Tue, Feb 20, 2018 at 11:58:41AM +, Andrew Cooper wrote: > Having pv_soft_rdtsc() emulate all parts of an rdtscp is awkward, and gets in > the way of some intended cleanup. > > * Drop the rdtscp parameter and always make the caller responsible for ecx >updates when appropriate. > *

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

>>> On 20.02.18 at 15:37, wrote: > --- a/tools/firmware/xen-dir/Makefile > +++ b/tools/firmware/xen-dir/Makefile > @@ -48,13 +48,14 @@ shim-%config: $(D) FORCE > KCONFIG_CONFIG=$(CURDIR)/shim.config > > xen-shim: $(D) shim-olddefconfig > - $(MAKE) -C

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

Roger Pau Monné writes ("Re: [PATCH] build: remove shim related targets"): > On Tue, Feb 20, 2018 at 03:09:18PM +, Ian Jackson wrote: > > Roger Pau Monne writes ("[PATCH] build: remove shim related targets"): > > > There's no need to have shim specific targets, so just use the regular > > >

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

On Tue, Feb 20, 2018 at 03:09:18PM +, Ian Jackson wrote: > Roger Pau Monne writes ("[PATCH] build: remove shim related targets"): > > There's no need to have shim specific targets, so just use the regular > > xen makefile targets in order to build the shim binary. > > I haven't been following

Re: [Xen-devel] [PATCH 2/5] x86/pv: Avoid leaking other guests' MSR_TSC_AUX values into PV context

On Tue, Feb 20, 2018 at 11:58:40AM +, Andrew Cooper wrote: > If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the value in > MSR_TSC_AUX, irrespective of whether the relevant CPUID features are > advertised/hidden. > > At the moment, paravirt_ctxt_switch_to() only writes to

Re: [Xen-devel] [PATCH 3/5] x86/time: Rework pv_soft_rdtsc() to aid further cleanup

On Tue, Feb 20, 2018 at 11:58:41AM +, Andrew Cooper wrote: > Having pv_soft_rdtsc() emulate all parts of an rdtscp is awkward, and gets in > the way of some intended cleanup. > > * Drop the rdtscp parameter and always make the caller responsible for ecx >updates when appropriate. > *

Re: [Xen-devel] [PATCH 2/5] x86/pv: Avoid leaking other guests' MSR_TSC_AUX values into PV context

On Tue, Feb 20, 2018 at 03:26:20PM +, Andrew Cooper wrote: > On 20/02/18 15:22, Wei Liu wrote: > > On Tue, Feb 20, 2018 at 11:58:40AM +, Andrew Cooper wrote: > >> If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the > >> value in > >> MSR_TSC_AUX, irrespective of whether

Re: [Xen-devel] [PATCH 2/5] x86/pv: Avoid leaking other guests' MSR_TSC_AUX values into PV context

On Tue, Feb 20, 2018 at 11:58:40AM +, Andrew Cooper wrote: > If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the value in > MSR_TSC_AUX, irrespective of whether the relevant CPUID features are > advertised/hidden. > This setup works only because CR4.TSD=0? > At the moment,

Re: [Xen-devel] [OSSTEST PATCH v2 00/19] Upgrade to Stretch

Wei Liu writes ("Re: [OSSTEST PATCH v2 00/19] Upgrade to Stretch"): > IIRC Ian suggested you copy one of the udev rules from Jessie's d-i to > the initrd osstest generated for stretch, and perhaps copy it to the > installed OS as well. I can't remember which files and don't have a > jessie system

Re: [Xen-devel] [PATCH 1/5] x86/hvm: Don't shadow the domain parameter in hvm_save_cpu_msrs()

On Tue, Feb 20, 2018 at 11:58:39AM +, Andrew Cooper wrote: > c/s d2f86bf604 which introduced "struct hvm_save_descriptor *d" accidentally > ended up shadowing the "struct domain *d" function parameter. Rename the > former to desc. > > No functional change. > > Signed-off-by: Andrew Cooper

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

Roger Pau Monne writes ("[PATCH] build: remove shim related targets"): > There's no need to have shim specific targets, so just use the regular > xen makefile targets in order to build the shim binary. I haven't been following this, mostly because I've been away, but: Previously (in the Comet

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

On Tue, Feb 20, 2018 at 02:43:25PM +, Wei Liu wrote: > On Tue, Feb 20, 2018 at 02:37:54PM +, Roger Pau Monne wrote: > > xen-shim: $(D) shim-olddefconfig > > - $(MAKE) -C $(D)/xen install-shim \ > > + $(MAKE) -C $(D)/xen build \ > > XEN_CONFIG_EXPERT=y \ > > -

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

On Tue, Feb 20, 2018 at 02:42:27PM +, Andrew Cooper wrote: > On 20/02/18 14:37, Roger Pau Monne wrote: > > diff --git a/tools/firmware/xen-dir/Makefile > > b/tools/firmware/xen-dir/Makefile > > index 7fd36a0e15..01a2850194 100644 > > --- a/tools/firmware/xen-dir/Makefile > > +++

Re: [Xen-devel] [PATCH 1/5] x86/hvm: Don't shadow the domain parameter in hvm_save_cpu_msrs()

On Tue, Feb 20, 2018 at 11:58:39AM +, Andrew Cooper wrote: > c/s d2f86bf604 which introduced "struct hvm_save_descriptor *d" accidentally > ended up shadowing the "struct domain *d" function parameter. Rename the > former to desc. > > No functional change. > > Signed-off-by: Andrew Cooper

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

On Tue, Feb 20, 2018 at 02:37:54PM +, Roger Pau Monne wrote: > xen-shim: $(D) shim-olddefconfig > - $(MAKE) -C $(D)/xen install-shim \ > + $(MAKE) -C $(D)/xen build \ > XEN_CONFIG_EXPERT=y \ > - KCONFIG_CONFIG=$(CURDIR)/shim.config \ > -

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

On 20/02/18 14:37, Roger Pau Monne wrote: > diff --git a/tools/firmware/xen-dir/Makefile b/tools/firmware/xen-dir/Makefile > index 7fd36a0e15..01a2850194 100644 > --- a/tools/firmware/xen-dir/Makefile > +++ b/tools/firmware/xen-dir/Makefile > @@ -48,13 +48,14 @@ shim-%config: $(D) FORCE >

Re: [Xen-devel] [OSSTEST PATCH v2 00/19] Upgrade to Stretch

On Tue, Feb 20, 2018 at 01:38:12PM +, Julien Grall wrote: > Hi Wei, > > On 31/10/17 13:51, Wei Liu wrote: > > First version of this series can be found at [0]. > > > > This version contains workaround for Arndale boards. They are now > > functional. > > I need the following patch [1] to

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

There's no need to have shim specific targets, so just use the regular xen makefile targets in order to build the shim binary. When the shim is build as part of the firmware directory install the stripped Xen binary to the firmware directory and place a binary with symbols in the debug directory.

[Xen-devel] [PATCH v5 2/5] build: filter out command line assembler arguments

If the assembler is not used. This happens when using cc -E or cc -S for example. GCC will just ignore the -Wa,... when the assembler is not called, but clang will complain loudly and fail. Also enable passing -Wa,-I$(BASEDIR)/include to clang now that it's safe to do so. Signed-off-by: Roger

[Xen-devel] [PATCH v5 1/5] build: do not hardcode AFLAGS for as-insn tests

Hardcoding as-insn to use AFLAGS is not correct. For once the test is performed using a C file with inline assembly, and secondly the flags used can be passed by the caller together with the CC. Fix as-insn-check to pass the flags given as parameter to the test. Signed-off-by: Roger Pau Monné

[Xen-devel] [PATCH v5 0/5] clang improvements

Hello, The following series re-enable the integrated clang assembler when the features required in order to build Xen are available. This series has been tested with clang 6, clang 3.5, gcc 6 and gcc 7 with indirect branch support. Thanks, Roger. Roger Pau Monne (5): build: do not hardcode

[Xen-devel] [PATCH v5 5/5] build/clang: add a check whether the assembler supports .skip with labels

Or else disable the integrated assembler for assembly files. This is relevant for older clang versions which integrated assembler don't support .skip with labels. Signed-off-by: Roger Pau Monné --- Cc: Andrew Cooper Cc: George Dunlap

[Xen-devel] [PATCH v5 3/5] x86/clang: restore integrated assembler usage with indirect thunks

If the required features are met by the integrated clang assembler (support for .includes and propagation of .macro-s between asm()-s) do not disable it. Only disable the integrated assembler for assembly files, like it was done prior to "x86: Support indirect thunks from assembly code".

[Xen-devel] [PATCH v5 4/5] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

When indirect_thunk_asm.h is instantiated directly into assembly files CONFIG_INDIRECT_THUNK might not be defined, and thus using .if against it is wrong. Add a check to define CONFIG_INDIRECT_THUNK to 0 if not defined, so that using .if CONFIG_INDIRECT_THUNK is always correct. This suppresses

Re: [Xen-devel] [OSSTEST PATCH v2 00/19] Upgrade to Stretch

Hi Wei, On 31/10/17 13:51, Wei Liu wrote: > First version of this series can be found at [0]. > > This version contains workaround for Arndale boards. They are now functional. I need the following patch [1] to use that branch on Arm64 boxes. Also, on Thunder-X I needed a hack to keep the

Re: [Xen-devel] [PATCH v4 3/4] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

On Tue, Feb 20, 2018 at 05:53:08AM -0700, Jan Beulich wrote: > >>> On 20.02.18 at 13:42, wrote: > > On Tue, Feb 20, 2018 at 05:32:17AM -0700, Jan Beulich wrote: > >> >>> On 20.02.18 at 12:22, wrote: > >> > On Tue, Feb 20, 2018 at 04:13:42AM -0700, Jan

Re: [Xen-devel] [PATCH v4 3/4] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

>>> On 20.02.18 at 13:42, wrote: > On Tue, Feb 20, 2018 at 05:32:17AM -0700, Jan Beulich wrote: >> >>> On 20.02.18 at 12:22, wrote: >> > On Tue, Feb 20, 2018 at 04:13:42AM -0700, Jan Beulich wrote: >> >> >>> On 20.02.18 at 12:01,

Re: [Xen-devel] [PATCH v4 3/4] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

On Tue, Feb 20, 2018 at 05:32:17AM -0700, Jan Beulich wrote: > >>> On 20.02.18 at 12:22, wrote: > > On Tue, Feb 20, 2018 at 04:13:42AM -0700, Jan Beulich wrote: > >> >>> On 20.02.18 at 12:01, wrote: > >> > --- a/xen/include/asm-x86/asm_defns.h > >> >

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

Any thoughts are appreciated. > This patch is adding a way to enable/disable nested pagefault > events. It introduces the xc_monitor_nested_pagefault function > and adds the nested_pagefault_disabled in the monitor structure. > This is needed by the introspection so it will only get gla > faults

Re: [Xen-devel] [PATCH v4 3/4] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

>>> On 20.02.18 at 12:22, wrote: > On Tue, Feb 20, 2018 at 04:13:42AM -0700, Jan Beulich wrote: >> >>> On 20.02.18 at 12:01, wrote: >> > --- a/xen/include/asm-x86/asm_defns.h >> > +++ b/xen/include/asm-x86/asm_defns.h >> > @@ -15,6 +15,9 @@ >> >

[Xen-devel] [PATCH 3/5] x86/time: Rework pv_soft_rdtsc() to aid further cleanup

Having pv_soft_rdtsc() emulate all parts of an rdtscp is awkward, and gets in the way of some intended cleanup. * Drop the rdtscp parameter and always make the caller responsible for ecx updates when appropriate. * Switch the function from being void, and return the main timestamp in the

[Xen-devel] [PATCH 1/5] x86/hvm: Don't shadow the domain parameter in hvm_save_cpu_msrs()

c/s d2f86bf604 which introduced "struct hvm_save_descriptor *d" accidentally ended up shadowing the "struct domain *d" function parameter. Rename the former to desc. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei

[Xen-devel] [PATCH 4/5] x86/pv: Remove deferred RDTSC{, P} handling in pv_emulate_privileged_op()

The handling of RDTSCP for PV guests has been broken (AFAICT forever). To start with, RDTSCP is hidden from PV guests so the MSR_TSC_AUX path should be unreachable. However, this appears to be a "feature" of TSC_MODE_PVRDTSCP, and the emulator doesn't perform appropriate feature checking.

[Xen-devel] [PATCH 5/5] x86: Rework MSR_TSC_AUX handling from scratch.

There are many problems with MSR_TSC_AUX handling. To being with, the RDPID instruction reads MSR_TSC_AUX, but it is only the RDTSCP feature which enumerates the MSR. Therefore, RDPID functionally depends on RDTSCP. For PV guests, we hide RDTSCP but advertise RDPID. We also silently drop

[Xen-devel] [RFC PATCH 0/5] x86: Multiple fixes to MSR_TSC_AUX and RDTSCP handling for guests

This rats nest was discovered when finding that MSR_TSC_AUX leaked into PV guests. It is RFC because I haven't done extensive testing on the result, and because there are some functional changes for the virtualised TSC modes. Andrew Cooper (5): x86/hvm: Don't shadow the domain parameter in

[Xen-devel] [PATCH 2/5] x86/pv: Avoid leaking other guests' MSR_TSC_AUX values into PV context

If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the value in MSR_TSC_AUX, irrespective of whether the relevant CPUID features are advertised/hidden. At the moment, paravirt_ctxt_switch_to() only writes to MSR_TSC_AUX if TSC_MODE_PVRDTSCP mode is enabled, but this is not the

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

flight 119721 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/119721/ 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 6/6] xen/arm: update the docs about heterogeneous computing

Hi Stefano, On 19/02/18 21:58, Stefano Stabellini wrote: diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index 2184cb9..8997904 100644 --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -1007,7 +1007,12 @@ Control Xens

Re: [Xen-devel] RTDS with extra time issue

Hello Dario, On 16.02.18 20:37, Dario Faggioli wrote: And what is it that is running in DomR, the same thing as before, when the load was synthetic? For sure I compare apples to apples. And in any case, is it, in its turn (I mean the workload running in DomR) a synthetic real-time load, or

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

On Tue, Feb 20, 2018 at 11:29:58AM +, Wei Liu wrote: > On Tue, Feb 20, 2018 at 11:26:44AM +, Roger Pau Monné wrote: > > On Tue, Feb 20, 2018 at 11:17:47AM +, Wei Liu wrote: > > > On Tue, Feb 20, 2018 at 08:23:51AM +, Roger Pau Monne wrote: > > > > There's no need to have shim

Re: [Xen-devel] [PATCH v2 5/6] xen/arm: read cacheline size when needed

Hi Stefano, On 19/02/18 21:58, Stefano Stabellini wrote: On big.LITTLE systems the cacheline size might differ between big and LITTLE cores. Instead of reading the cacheline size once at boot, read it as needed from the system registers. Suggested-by: Julien Grall

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

On Tue, Feb 20, 2018 at 11:26:44AM +, Roger Pau Monné wrote: > On Tue, Feb 20, 2018 at 11:17:47AM +, Wei Liu wrote: > > On Tue, Feb 20, 2018 at 08:23:51AM +, Roger Pau Monne wrote: > > > There's no need to have shim specific targets, so just use the regular > > > xen makefile targets

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

On Tue, Feb 20, 2018 at 11:17:47AM +, Wei Liu wrote: > On Tue, Feb 20, 2018 at 08:23:51AM +, Roger Pau Monne wrote: > > There's no need to have shim specific targets, so just use the regular > > xen makefile targets in order to build the shim binary. > > > > When the shim is build as part

Re: [Xen-devel] [PATCH v4 3/4] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

On Tue, Feb 20, 2018 at 04:13:42AM -0700, Jan Beulich wrote: > >>> On 20.02.18 at 12:01, wrote: > > --- a/xen/include/asm-x86/asm_defns.h > > +++ b/xen/include/asm-x86/asm_defns.h > > @@ -15,6 +15,9 @@ > > #include > > > > #ifdef __ASSEMBLY__ > > +#ifndef

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

On Tue, Feb 20, 2018 at 08:23:51AM +, Roger Pau Monne wrote: > There's no need to have shim specific targets, so just use the regular > xen makefile targets in order to build the shim binary. > > When the shim is build as part of the firmware directory use the > xen-syms as the shim binary. >

Re: [Xen-devel] [PATCH v4 3/4] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

>>> On 20.02.18 at 12:01, wrote: > --- a/xen/include/asm-x86/asm_defns.h > +++ b/xen/include/asm-x86/asm_defns.h > @@ -15,6 +15,9 @@ > #include > > #ifdef __ASSEMBLY__ > +#ifndef CONFIG_INDIRECT_THUNK > +.equ CONFIG_INDIRECT_THUNK, 0 > +#endif > # include > #else >

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

>>> On 20.02.18 at 11:06, wrote: > On Tue, Feb 20, 2018 at 02:04:24AM -0700, Jan Beulich wrote: >> >>> On 20.02.18 at 09:23, wrote: >> > --- a/tools/firmware/xen-dir/Makefile >> > +++ b/tools/firmware/xen-dir/Makefile >> > @@ -48,10 +48,10 @@

Re: [Xen-devel] [PATCH v2 4/6] xen/arm: make vpidr per vcpu

Hi Stefano, On 19/02/18 21:58, Stefano Stabellini wrote: On big.LITTLE systems not all cores have the same midr. Instead of storing only one vpidr per domain, make it per vcpu and initialize it to the value of the midr of the pcpu where the vcpu will run. This way, assuming that the vcpu has

Re: [Xen-devel] [PATCH v4 3/4] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

On Tue, Feb 20, 2018 at 10:19:16AM +, Roger Pau Monné wrote: > On Tue, Feb 20, 2018 at 02:15:24AM -0700, Jan Beulich wrote: > > >>> On 19.02.18 at 15:16, wrote: > > > --- a/xen/include/asm-x86/indirect_thunk_asm.h > > > +++ b/xen/include/asm-x86/indirect_thunk_asm.h > >

Re: [Xen-devel] [PATCH v2 3/6] xen/arm: read ACTLR on the pcpu where the vcpu will run

Hi Stefano, On 19/02/18 21:58, Stefano Stabellini wrote: On big.LITTLE systems not all cores have the same ACTLR. Instead of reading ACTLR and setting v->arch.actlr in vcpu_initialise, do it later on the same pcpu where the vcpu will run. This way, assuming that the vcpu has been created with

Re: [Xen-devel] [PATCH v1 2/2] hvm/svm: Implement CPUID events

On Lu, 2018-02-19 at 08:25 -0700, Tamas K Lengyel wrote: > On Mon, Feb 19, 2018 at 6:07 AM, Alexandru Isaila > wrote: > > > > At this moment the CPUID events for the AMD architecture are not > > forwarded to the monitor layer. > > > > This patch adds the CPUID event to

  1   2   >