Re: [Xen-devel] [PATCH 2/5] x86: split out cpuid objects and helpers

On Fri, May 25, 2018 at 11:41:04AM +0200, Roger Pau Monné wrote: > On Thu, May 24, 2018 at 05:05:19PM +0100, Wei Liu wrote: > > They are moved to a new header which is going to be consumed by both > > the hypervisor and toolstack. > > > > Create a new directory for this kind of headers in

Re: [Xen-devel] [PATCH for-4.11] x86/XPTI: Fix up stale comments concerning mappings

>>> On 25.05.18 at 12:52, wrote: > --- a/xen/arch/x86/smpboot.c > +++ b/xen/arch/x86/smpboot.c > @@ -794,7 +794,7 @@ static int setup_cpu_root_pgt(unsigned int cpu) > /* SH_LINEAR_PT inserted together with guest mappings. */ > /* PERDOMAIN inserted during

Re: [Xen-devel] [PATCH 1/5] x86: move definition of struct cpuid_leaf to cpuid.h

On Fri, May 25, 2018 at 11:31:17AM +0200, Roger Pau Monné wrote: > On Thu, May 24, 2018 at 05:05:18PM +0100, Wei Liu wrote: > > This is a step towards consolidating relevant data structures and > > defines to one location. > > > > It then requires defining cpuid_leaf in user space harness headers

Re: [Xen-devel] [PATCH] libxc/x86/PV: don't hand through CPUID leaf 0x80000008 as is

Andrew Cooper writes ("Re: [PATCH] libxc/x86/PV: don't hand through CPUID leaf 0x8008 as is"): > On 22/05/18 12:41, Wei Liu wrote: > > On Tue, May 22, 2018 at 05:40:02AM -0600, Jan Beulich wrote: > >> Just like for HVM the feature set should be used for EBX output, while > >> EAX should be

Re: [Xen-devel] [PATCH 9/9] x86/vmx: Don't leak EFER.NXE into guest context

On 25/05/18 12:36, Jan Beulich wrote: On 25.05.18 at 10:36, wrote: >> On 25/05/2018 08:49, Jan Beulich wrote: >> On 22.05.18 at 13:20, wrote: @@ -1650,22 +1641,81 @@ static void vmx_update_guest_cr(struct vcpu *v, >> unsigned

Re: [Xen-devel] [PATCH v3 11/27] x86/power/64: Adapt assembly for PIE support

On Thu 2018-05-24 09:37:20, Thomas Garnier wrote: > On Thu, May 24, 2018 at 4:04 AM Pavel Machek wrote: > > > On Wed 2018-05-23 12:54:05, Thomas Garnier wrote: > > > Change the assembly code to use only relative references of symbols for > the > > > kernel to be PIE compatible. > >

Re: [Xen-devel] [PATCH 2/5] x86: split out cpuid objects and helpers

On Fri, May 25, 2018 at 11:01:18AM +0100, Andrew Cooper wrote: > On 25/05/18 10:49, Wei Liu wrote: > > On Fri, May 25, 2018 at 11:41:04AM +0200, Roger Pau Monné wrote: > >> On Thu, May 24, 2018 at 05:05:19PM +0100, Wei Liu wrote: > >>> They are moved to a new header which is going to be consumed

Re: [Xen-devel] [PATCH for-4.11] x86/XPTI: Fix up stale comments concerning mappings

>>> On 25.05.18 at 13:31, wrote: > On 25/05/18 12:17, Jan Beulich wrote: > On 25.05.18 at 12:52, wrote: >>> --- a/xen/arch/x86/smpboot.c >>> +++ b/xen/arch/x86/smpboot.c >>> @@ -794,7 +794,7 @@ static int setup_cpu_root_pgt(unsigned int

Re: [Xen-devel] [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Thu, May 24, 2018 at 05:29:43PM +0200, Michal Hocko wrote: > > ie if we had more, > > could we solve our pain by making them more generic? > > Well, if you have more you will consume more bits in the struct pages, > right? Not necessarily ... the zone number is stored in the struct page

[Xen-devel] [PATCH] xen/svm: don't clear interception for MSRs required for introspection

This patch mirrors the VMX code that doesn't allow vmx_disable_intercept_for_msr() to clear interception of MSRs that an introspection agent is trying to monitor. Signed-off-by: Razvan Cojocaru --- xen/arch/x86/hvm/svm/svm.c | 5 +++-- 1 file changed, 3 insertions(+),

Re: [Xen-devel] [External] Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

From: Michal Hocko [mailto:mho...@kernel.org] Sent: Thursday, May 24, 2018 8:19 PM> > > Let me try to reply your questions. > > Exactly, GFP_ZONE_TABLE is too complicated. I think there are two advantages > > from the series of patches. > > > > 1. XOR operation is simple and efficient,

Re: [Xen-devel] [PATCH 2/5] x86: split out cpuid objects and helpers

On 25/05/18 10:49, Wei Liu wrote: > On Fri, May 25, 2018 at 11:41:04AM +0200, Roger Pau Monné wrote: >> On Thu, May 24, 2018 at 05:05:19PM +0100, Wei Liu wrote: >>> They are moved to a new header which is going to be consumed by both >>> the hypervisor and toolstack. >>> >>> Create a new directory

Re: [Xen-devel] [PATCH] libxc/x86/PV: don't hand through CPUID leaf 0x80000008 as is

On 22/05/18 12:41, Wei Liu wrote: > On Tue, May 22, 2018 at 05:40:02AM -0600, Jan Beulich wrote: >> Just like for HVM the feature set should be used for EBX output, while >> EAX should be restricted to the low 16 bits and ECX/EDX should be zero. >> >> Signed-off-by: Jan Beulich

[Xen-devel] [PATCH] x86: correct default_xen_spec_ctrl calculation

Even with opt_msr_sc_{pv,hvm} both false we should set up the variable as usual, to ensure proper one-time setup during boot and CPU bringup. This then also brings the code in line with the comment immediately ahead of the printk() being modified saying "irrespective of guests". Signed-off-by:

Re: [Xen-devel] [PATCH 9/9] x86/vmx: Don't leak EFER.NXE into guest context

On 25/05/2018 08:49, Jan Beulich wrote: On 22.05.18 at 13:20, wrote: >> @@ -1650,22 +1641,81 @@ static void vmx_update_guest_cr(struct vcpu *v, >> unsigned int cr, >> >> static void vmx_update_guest_efer(struct vcpu *v) >> { >> -unsigned long

Re: [Xen-devel] [PATCH 1/5] x86: move definition of struct cpuid_leaf to cpuid.h

On Thu, May 24, 2018 at 05:05:18PM +0100, Wei Liu wrote: > This is a step towards consolidating relevant data structures and > defines to one location. > > It then requires defining cpuid_leaf in user space harness headers to > make them continue to compile. > > No functional change. > >

Re: [Xen-devel] [PATCH 2/5] x86: split out cpuid objects and helpers

On Thu, May 24, 2018 at 05:05:19PM +0100, Wei Liu wrote: > They are moved to a new header which is going to be consumed by both > the hypervisor and toolstack. > > Create a new directory for this kind of headers in anticipation of

[Xen-devel] [xen-4.9-testing test] 123122: tolerable FAIL - PUSHED

flight 123122 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/123122/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail in 122960 pass in 123122

Re: [Xen-devel] [PATCH v2] x86/XPTI: fix S3 resume (and CPU offlining in general)

On 25/05/18 07:02, Jan Beulich wrote: > We should index an L1 table with an L1 index. > > Reported-by: Simon Gaiser > Signed-off-by: Jan Beulich Indeed we should. Reviewed-by: Andrew Cooper , and I've got a followup

Re: [Xen-devel] [PATCH 1/5] x86: move definition of struct cpuid_leaf to cpuid.h

On Fri, May 25, 2018 at 05:50:12AM -0600, Jan Beulich wrote: > >>> On 24.05.18 at 18:05, wrote: > > This is a step towards consolidating relevant data structures and > > defines to one location. > > Sort of contrary to what the patch does - it converts one instance of the >

Re: [Xen-devel] [PATCH] x86: correct default_xen_spec_ctrl calculation

On 25/05/18 12:08, Jan Beulich wrote: > Even with opt_msr_sc_{pv,hvm} both false we should set up the variable > as usual, to ensure proper one-time setup during boot and CPU bringup. > This then also brings the code in line with the comment immediately > ahead of the printk() being modified

[Xen-devel] [PATCH for-4.11] x86/XPTI: Fix up stale comments concerning mappings

The comments became stale when c/s d1d6fc97d66 "x86/xpti: really hide almost all of Xen image" altered how the stubs were mapped. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Juergen Gross --- xen/arch/x86/smpboot.c | 4

Re: [Xen-devel] [PATCH for-4.11] x86/XPTI: Fix up stale comments concerning mappings

On 25/05/18 12:17, Jan Beulich wrote: On 25.05.18 at 12:52, wrote: >> --- a/xen/arch/x86/smpboot.c >> +++ b/xen/arch/x86/smpboot.c >> @@ -794,7 +794,7 @@ static int setup_cpu_root_pgt(unsigned int cpu) >> /* SH_LINEAR_PT inserted together with guest mappings.

Re: [Xen-devel] [PATCH v3 09/27] x86/acpi: Adapt assembly for PIE support

On Thu 2018-05-24 09:35:42, Thomas Garnier wrote: > On Thu, May 24, 2018 at 4:03 AM Pavel Machek wrote: > > > On Wed 2018-05-23 12:54:03, Thomas Garnier wrote: > > > Change the assembly code to use only relative references of symbols for > the > > > kernel to be PIE compatible. > >

Re: [Xen-devel] [PATCH for-4.11] tools: set DEBUG_DIR from configure

On Tue, Mar 27, Roger Pau Monne wrote: > Allow the path to be set from a configure command line option. Please backport 641f9ce2fa to 4.10 ASAP. See https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg02749.html Thanks. Olaf signature.asc Description: PGP signature

[Xen-devel] [OSSTEST PATCH] ap-common: Switch to Linux 4.14 by default on X86.

Linux 4.9 is getting a bit long in the tooth. 4.14 is an LTS branch and the osstest-tested version seems reasonably good. I ran a special report[1] to see what to expect and it reported no regressions. Accordingly I am going to switch to using Linux 4.14 by default for most X86 runs in osstest.

Re: [Xen-devel] [OSSTEST PATCH] ap-common: Switch to Linux 4.14 by default on X86.

Hi Ian, Would it be possible to update your CC with my Arm e-mail from now on? On 25/05/18 15:44, Ian Jackson wrote: Linux 4.9 is getting a bit long in the tooth. 4.14 is an LTS branch and the osstest-tested version seems reasonably good. I ran a special report[1] to see what to expect and

[Xen-devel] [PATCH 3/8] drm/xen-front: fix 32-bit build warning

In 32-bit kernel builds, we cannot cast between a pointer and a 64-bit type: In file included from drivers/gpu/drm/xen/xen_drm_front_cfg.c:18: drivers/gpu/drm/xen/xen_drm_front.h: In function 'xen_drm_front_fb_to_cookie': drivers/gpu/drm/xen/xen_drm_front.h:129:9: error: cast from pointer to

[Xen-devel] [xen-4.10-testing baseline-only test] 74742: regressions - FAIL

This run is configured for baseline tests only. flight 74742 xen-4.10-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74742/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-win10-i386 10

Re: [Xen-devel] [OSSTEST PATCH] ap-common: Switch to Linux 4.14 by default on X86.

On Fri, May 25, 2018 at 03:44:53PM +0100, Ian Jackson wrote: > Linux 4.9 is getting a bit long in the tooth. 4.14 is an LTS branch > and the osstest-tested version seems reasonably good. I ran a special > report[1] to see what to expect and it reported no regressions. > > Accordingly I am going

Re: [Xen-devel] [PATCH for-4.11] tools: set DEBUG_DIR from configure

Olaf Hering writes ("Re: [Xen-devel] [PATCH for-4.11] tools: set DEBUG_DIR from configure"): > On Tue, Mar 27, Roger Pau Monne wrote: > > > Allow the path to be set from a configure command line option. > > Please backport 641f9ce2fa to 4.10 ASAP. See >

[Xen-devel] [PATCH 0/8] xen: dma-buf support for grant device

From: Oleksandr Andrushchenko This work is in response to my previous attempt to introduce Xen/DRM zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based frontends/backends. There is also an existing hyper_dmabuf approach available [3] which, if

[Xen-devel] [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module

From: Oleksandr Andrushchenko Memory {increase|decrease}_reservation and VA mappings update/reset code used in balloon driver can be made common, so other drivers can also re-use the same functionality without open-coding. Create a dedicated module for the

[Xen-devel] [PATCH 8/8] xen/gntdev: Expose gntdev's dma-buf API for in-kernel use

From: Oleksandr Andrushchenko Allow creating grant device context for use by kernel modules which require functionality, provided by gntdev. Export symbols for dma-buf API provided by the module. Signed-off-by: Oleksandr Andrushchenko

[Xen-devel] [PATCH 6/8] xen/gntdev: Implement dma-buf export functionality

From: Oleksandr Andrushchenko 1. Create a dma-buf from grant references provided by the foreign domain. By default dma-buf is backed by system memory pages, but by providing GNTDEV_DMA_FLAG_XXX flags it can also be created as a DMA

[Xen-devel] [PATCH 1/8] xen/grant-table: Make set/clear page private code shared

From: Oleksandr Andrushchenko Make set/clear page private code shared and accessible to other kernel modules which can re-use these instead of open-coding. Signed-off-by: Oleksandr Andrushchenko --- drivers/xen/grant-table.c

Re: [Xen-devel] [PATCH] x86/CPUID: don't override tool stack decision to hide STIBP

On 25/05/18 08:17, Jan Beulich wrote: On 24.05.18 at 18:44, wrote: >> On 22/05/18 11:33, Jan Beulich wrote: >>> Other than in the feature sets, where we indeed want to offer the >>> feature even if not enumerated on hardware, we shouldn't dictate the >>> feature

Re: [Xen-devel] [PATCH v1] libxl: always call qemus xen-save-devices-state in suspend/resume

Am Tue, 22 May 2018 12:14:29 +0100 schrieb Wei Liu : > I think your predicate is correct. Sorry for the noise. Is there anything else to be done to get this fixed? Olaf pgpyQZGDs0CyK.pgp Description: Digitale Signatur von OpenPGP

[Xen-devel] [PATCH 5/8] xen/gntdev: Add initial support for dma-buf UAPI

From: Oleksandr Andrushchenko Add UAPI and IOCTLs for dma-buf grant device driver extension: the extension allows userspace processes and kernel modules to use Xen backed dma-buf implementation. With this extension grant references to the pages of an imported

[Xen-devel] [PATCH 4/8] xen/gntdev: Allow mappings for DMA buffers

From: Oleksandr Andrushchenko Allow mappings for DMA backed buffers if grant table module supports such: this extends grant device to not only map buffers made of balloon pages, but also from buffers allocated with dma_alloc_xxx. Signed-off-by: Oleksandr

[Xen-devel] [PATCH 7/8] xen/gntdev: Implement dma-buf import functionality

From: Oleksandr Andrushchenko 1. Import a dma-buf with the file descriptor provided and export granted references to the pages of that dma-buf into the array of grant references. 2. Add API to close all references to an imported buffer, so it can be

Re: [Xen-devel] [PATCH] x86/CPUID: don't override tool stack decision to hide STIBP

>>> On 25.05.18 at 15:52, wrote: > On 25/05/18 08:17, Jan Beulich wrote: > On 24.05.18 at 18:44, wrote: >>> On 22/05/18 11:33, Jan Beulich wrote: Other than in the feature sets, where we indeed want to offer the feature even if

Re: [Xen-devel] [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation

On Thu, 24 May 2018, Julien Grall wrote: > Hi Stefano, > > On 23/05/18 23:34, Stefano Stabellini wrote: > > On Tue, 22 May 2018, Julien Grall wrote: > > > On a system where the firmware implements ARCH_WORKAROUND_2, it may be > > > useful to either permanently enable or disable the workaround for

Re: [Xen-devel] [PATCH 08/13] xen/arm: alternatives: Add dynamic patching feature

On Tue, 22 May 2018, Julien Grall wrote: > This is based on the Linux commit dea5e2a4c5bc "arm64: alternatives: Add > dynamic patching feature" written by Marc Zyngier: > > We've so far relied on a patching infrastructure that only gave us > a single alternative, without any way to

Re: [Xen-devel] [PATCH 06/13] xen/arm: Add ARCH_WORKAROUND_2 support for guests

On Thu, 24 May 2018, Julien Grall wrote: > Hi Stefano, > > On 24/05/18 01:40, Stefano Stabellini wrote: > > On Wed, 23 May 2018, Stefano Stabellini wrote: > > > On Tue, 22 May 2018, Julien Grall wrote: > > > > In order to offer ARCH_WORKAROUND_2 support to guests, we need to track > > > > the > >

Re: [Xen-devel] [PATCH 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing

On Wed, 23 May 2018, Julien Grall wrote: > Hi, > > On 05/23/2018 10:57 PM, Stefano Stabellini wrote: > > On Tue, 22 May 2018, Julien Grall wrote: > > > As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery > > > mechanism for detecting the SSBD mitigation. > > > > > > A new

Re: [Xen-devel] [PATCH 01/13] xen/arm: domain: Zeroed the vCPU stack

On Tue, 22 May 2018, Julien Grall wrote: > A stack is allocated per vCPU to be used by Xen. The allocation is done > with alloc_xenheap_pages that does not zero the memory returned. However > the top of the stack is containing information that will be used to > store the initial state of the vCPU

Re: [Xen-devel] [PATCH 1/5] x86: move definition of struct cpuid_leaf to cpuid.h

On 25/05/18 14:05, Jan Beulich wrote: On 25.05.18 at 14:03, wrote: >> On Fri, May 25, 2018 at 05:50:12AM -0600, Jan Beulich wrote: >> On 24.05.18 at 18:05, wrote: This is a step towards consolidating relevant data structures and

Re: [Xen-devel] [PATCH 1/5] x86: move definition of struct cpuid_leaf to cpuid.h

>>> On 25.05.18 at 14:03, wrote: > On Fri, May 25, 2018 at 05:50:12AM -0600, Jan Beulich wrote: >> >>> On 24.05.18 at 18:05, wrote: >> > This is a step towards consolidating relevant data structures and >> > defines to one location. >> >> Sort of

Re: [Xen-devel] [OSSTEST PATCH] ap-common: Switch to Linux 4.14 by default on X86.

Julien Grall writes ("Re: [Xen-devel] [OSSTEST PATCH] ap-common: Switch to Linux 4.14 by default on X86."): > Would it be possible to update your CC with my Arm e-mail from now on? Sorry, I copied it from an old commit. > FWIW, linux-arm-xen branch is using 4.14.9. I had to upgrade it in order

Re: [Xen-devel] [PATCH] xen/svm: don't clear interception for MSRs required for introspection

On 05/25/2018 06:19 PM, Boris Ostrovsky wrote: > On 05/25/2018 08:38 AM, Razvan Cojocaru wrote: >> This patch mirrors the VMX code that doesn't allow >> vmx_disable_intercept_for_msr() > > vmx_clear_msr_intercept() ? > >> to clear interception of MSRs that >> an introspection agent is trying to

Re: [Xen-devel] MSR_SPEC_CTRL intercept

On 24/05/18 11:23, Jan Beulich wrote: On 24.05.18 at 12:13, wrote: >> On 24/05/18 09:13, Jan Beulich wrote: >> On 24.05.18 at 00:09, wrote: It is, as documented, not completely strictly true (according to the latest

Re: [Xen-devel] MSR_SPEC_CTRL intercept

>>> On 25.05.18 at 17:25, wrote: > On 24/05/18 11:23, Jan Beulich wrote: > On 24.05.18 at 12:13, wrote: >>> On 24/05/18 09:13, Jan Beulich wrote: >>> On 24.05.18 at 00:09, wrote: > It is, as documented,

Re: [Xen-devel] [PATCH v3 09/27] x86/acpi: Adapt assembly for PIE support

On Fri, May 25, 2018 at 2:14 AM Pavel Machek wrote: > On Thu 2018-05-24 09:35:42, Thomas Garnier wrote: > > On Thu, May 24, 2018 at 4:03 AM Pavel Machek wrote: > > > > > On Wed 2018-05-23 12:54:03, Thomas Garnier wrote: > > > > Change the assembly code to use only

[Xen-devel] Schedule for our Annual Developer and Design Summit - Design Session Rating and Proposals

Schedule for our Annual Developer and Design Summit We are excited to announce the program and speakers for the Xen Project Developer and Design Summit (https://www.lfasiallc.com/events/xensummit2018/). The summit brings together developers, engineers, and Xen Project power users for in-person

[Xen-devel] [distros-debian-jessie test] 74743: tolerable FAIL

flight 74743 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74743/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like 74725 baseline version:

[Xen-devel] [linux-next test] 123129: regressions - trouble: broken/fail/pass

flight 123129 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/123129/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim broken

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

flight 123135 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/123135/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail REGR. vs.

Re: [Xen-devel] [OSSTEST PATCH] ap-common: Switch to Linux 4.14 by default on X86.

On Fri, May 25, 2018 at 03:44:53PM +0100, Ian Jackson wrote: > Linux 4.9 is getting a bit long in the tooth. 4.14 is an LTS branch > and the osstest-tested version seems reasonably good. I ran a special > report[1] to see what to expect and it reported no regressions. > > Accordingly I am going

Re: [Xen-devel] [PATCH 10/13] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_2

On Tue, 22 May 2018, Julien Grall wrote: > The function ARM_SMCCC_ARCH_WORKAROUND_2 will be called by the guest for > enabling/disabling the ssbd mitigation. So we want the handling to > be as fast as possible. > > The new sequence will forward guest's ARCH_WORKAROUND_2 call to EL3 and > also

[Xen-devel] [xen-4.7-testing test] 123144: tolerable FAIL - PUSHED

flight 123144 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/123144/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt 6 xen-install fail in 122971 pass in 123144

Re: [Xen-devel] [PATCH 07/13] xen/arm: Simplify alternative patching

On Fri, 25 May 2018, Julien Grall wrote: > On Fri, 25 May 2018, 22:54 Stefano Stabellini, wrote: > You might want to CC Konrad next time on this patch > > > May I ask why? This code falls under Arm maintainership. I know, but I appreciate his input if he has time

Re: [Xen-devel] [PATCH 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing

On 25/05/2018 21:51, Stefano Stabellini wrote: > On Wed, 23 May 2018, Julien Grall wrote: >> Hi, >> >> On 05/23/2018 10:57 PM, Stefano Stabellini wrote: >>> On Tue, 22 May 2018, Julien Grall wrote: As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery mechanism for

[Xen-devel] [linux-4.14 test] 123147: tolerable FAIL - PUSHED

flight 123147 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/123147/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt 6 xen-install fail in 123073 pass in 123147 test-armhf-armhf-xl 7

[Xen-devel] [xen-4.8-testing baseline-only test] 74744: regressions - FAIL

This run is configured for baseline tests only. flight 74744 xen-4.8-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74744/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-build

Re: [Xen-devel] [PATCH v5 0/6] Allow setting up shared memory areas between VMs from xl config files

Hi Stefano, Thank you very much for your fixes. It seems that you've addressed all the issues during the last round of reviews. I'm sorry for my off-and-on contribution time, which has largely delayed the process of merging the patch set. Please tell me if you need anything from me. Cheers,

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

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

Re: [Xen-devel] [PATCH 07/13] xen/arm: Simplify alternative patching

You might want to CC Konrad next time on this patch On Tue, 22 May 2018, Julien Grall wrote: > This is part of XSA-263. > > Signed-off-by: Julien Grall > > --- > I am aware of the missing commit message here. I wanted to send the > series on the ML to get some

Re: [Xen-devel] [PATCH 9/9] x86/vmx: Don't leak EFER.NXE into guest context

At 12:20 +0100 on 22 May (1526991646), Andrew Cooper wrote: > Intel hardware only uses 4 bits in MSR_EFER. Changes to LME and LMA are > handled automatically via the VMENTRY_CTLS.IA32E_MODE bit. > > SCE is handled by ad-hoc logic in context_switch(), vmx_restore_guest_msrs() > and

Re: [Xen-devel] [PATCH] tools/kdd: alternative way of muting spurious gcc warning

At 06:02 +0200 on 23 May (1527055365), Juergen Gross wrote: > On 22/05/18 21:47, Marek Marczykowski-Górecki wrote: > > Older gcc does not support #pragma GCC diagnostics, so use alternative > > approach - change variable type to uint32_t (this code handle 32-bit > > requests only anyway), which

Re: [Xen-devel] [v2 1/6] Port WARN_ON_ONCE() from Linux

>>> On 24.05.18 at 22:23, wrote: > > On 05/24/2018 01:53 AM, Jan Beulich wrote: > On 24.05.18 at 02:46, wrote: >>> Port WARN_ON_ONCE macro from Linux. >> In such a case you should justify adjustments you've made: > I can add more details, but

Re: [Xen-devel] [PATCH] x86/CPUID: don't override tool stack decision to hide STIBP

>>> On 24.05.18 at 18:44, wrote: > On 22/05/18 11:33, Jan Beulich wrote: >> Other than in the feature sets, where we indeed want to offer the >> feature even if not enumerated on hardware, we shouldn't dictate the >> feature being available if tool stack or host admin

[Xen-devel] [PATCH v2] x86/XPTI: fix S3 resume (and CPU offlining in general)

We should index an L1 table with an L1 index. Reported-by: Simon Gaiser Signed-off-by: Jan Beulich --- v2: Entirely different. --- a/xen/arch/x86/smpboot.c +++ b/xen/arch/x86/smpboot.c @@ -883,7 +883,7 @@ static void cleanup_cpu_root_pgt(unsigne

Re: [Xen-devel] [PATCH 9/9] x86/vmx: Don't leak EFER.NXE into guest context

>>> On 24.05.18 at 18:48, wrote: > On 24/05/18 17:01, Roger Pau Monné wrote: >> On Tue, May 22, 2018 at 12:20:46PM +0100, Andrew Cooper wrote: >>> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h >>> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h >>> @@ -306,6 +306,8 @@ extern u64

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

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

Re: [Xen-devel] [v2 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

>>> On 24.05.18 at 22:26, wrote: > On 05/24/2018 01:57 AM, Jan Beulich wrote: > On 24.05.18 at 02:46, wrote: >>> --- /dev/null >>> +++ b/xen/include/xen/linux_compat.h >> I continue to dislike the idea of having a header with these contents in

[Xen-devel] [xen-4.8-testing test] 123091: tolerable FAIL - PUSHED

flight 123091 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/123091/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 122991 pass in 123091

Re: [Xen-devel] [PATCH 9/9] x86/vmx: Don't leak EFER.NXE into guest context

On 25/05/2018 08:27, Jan Beulich wrote: On 24.05.18 at 18:48, wrote: >> On 24/05/18 17:01, Roger Pau Monné wrote: >>> On Tue, May 22, 2018 at 12:20:46PM +0100, Andrew Cooper wrote: --- a/xen/include/asm-x86/hvm/vmx/vmcs.h +++

Re: [Xen-devel] [PATCH 9/9] x86/vmx: Don't leak EFER.NXE into guest context

>>> On 22.05.18 at 13:20, wrote: > @@ -1650,22 +1641,81 @@ static void vmx_update_guest_cr(struct vcpu *v, > unsigned int cr, > > static void vmx_update_guest_efer(struct vcpu *v) > { > -unsigned long vm_entry_value; > +unsigned long entry_ctls, guest_efer

Re: [Xen-devel] xsa263 wont apply

>>> On 25.05.18 at 02:52, wrote: > I'm trying to apply xsa263 patches, specifically for 4.10. However they > dont seem to on top of 4.10.1 release. > > I see they do apply cleanly to current 4.10 staging branch. Are staging > trees for stable branches like 4.10