Re: [Xen-devel] [PATCH] x86: suppress sync when XPTI is disabled for a domain

>>> On 23.05.18 at 16:24, wrote: > Now that we have a per-domain flag we can and should control sync-ing in > a more fine grained manner: Only domains having XPTI enabled need the > sync to occur. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/mm.c

Re: [Xen-devel] [PATCH v2 10/10] xen: add cloc target

>>> On 23.05.18 at 20:21, wrote: > On Wed, 23 May 2018, Jan Beulich wrote: >> >>> On 22.05.18 at 22:08, wrote: >> > On Tue, 22 May 2018, Jan Beulich wrote: >> >> >>> On 22.05.18 at 02:53, wrote: >> >> > + $(eval

Re: [Xen-devel] MSR_SPEC_CTRL intercept

>>> On 24.05.18 at 00:09, wrote: > It is, as documented, not completely strictly true (according to the > latest revision of the spec), but is there deliberately to simply so we > don't give the guest implausible configurations. There is not a > processor with STIBP

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

>>> 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: > --- a/xen/include/xen/lib.h > +++ b/xen/include/xen/lib.h > @@ -11,6 +11,19 @@ > #define BUG_ON(p) do { if (unlikely(p)) BUG(); } while

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

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

Re: [Xen-devel] [v2 5/6] drivers/passthrough/arm: Refactor code for arm smmu drivers

>>> On 24.05.18 at 02:46, wrote: > Pull common defines for SMMU drives in a local header. > > Signed-off-by: Sameer Goel > --- > xen/drivers/passthrough/arm/arm_smmu.h | 125 + This being a local header - why the arm_

Re: [Xen-devel] [v2 6/6] xen/smmu: Add a new config define for legacy SMMU

>>> On 24.05.18 at 02:46, wrote: > --- a/xen/drivers/passthrough/arm/Makefile > +++ b/xen/drivers/passthrough/arm/Makefile > @@ -1,3 +1,3 @@ > obj-y += iommu.o > -obj-y += smmu.o > +obj-$(CONFIG_ARM_SMMU) += smmu.o > obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o Same question

Re: [Xen-devel] [PATCH v3 07/10] arm: make it possible to disable the SMMU driver

Hello Stefano, On 23.05.18 22:16, Stefano Stabellini wrote: I meant "default y" because I am only trying to introduce the options in this patch series, I am not trying to change the defaults (yet). In any case, even with "default y" it works as intended if you start from tiny.config. 1) cp

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

Hi Stefano, On 24/05/18 00:23, Stefano Stabellini wrote: On Tue, 22 May 2018, Julien Grall wrote: +extern enum ssbd_state ssbd_state; + +static inline enum ssbd_state get_ssbd_state(void) +{ +return ssbd_state; +} + DECLARE_PER_CPU(register_t, ssbd_callback_required); static inline

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

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 state of the workaround per-vCPU. The field 'pad' in cpu_info is now

Re: [Xen-devel] [PATCH v3 18/27] xen: Adapt assembly for PIE support

On 23/05/18 21:54, Thomas Garnier wrote: > Change the assembly code to use the new _ASM_MOVABS macro which get a > symbol reference while being PIE compatible. Adapt the relocation tool > to ignore 32-bit Xen code. > > Position Independent Executable (PIE) support will allow to extended the >

Re: [Xen-devel] MSR_SPEC_CTRL intercept

>>> 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 revision of the spec), but is there deliberately

Re: [Xen-devel] [PATCH 13/13] xen/arm: Avoid to use current everywhere in enter_hypervisor_head

Hi Stefano, On 24/05/18 00:47, Stefano Stabellini wrote: On Tue, 22 May 2018, Julien Grall wrote: Using current is fairly expensive, so save up into a variable. Signed-off-by: Julien Grall Good idea. I am curious to know actually how much this patch would save but I

[Xen-devel] Developmentstatus for Xen with Ceph as replicated storage

Hi everybody, in 2013 there was an announcment, that XenServer will fully support the RBDs from Ceph, to use them as blockdevice for VMs (see ) What is about Xen itself, how it is supported? I know that you can map an RBD as device and

Re: [Xen-devel] MSR_SPEC_CTRL intercept

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 revision of the spec), but is there deliberately to simply so we >> don't give the guest implausible configurations.

Re: [Xen-devel] Likely build race, "/usr/bin/ld: cannot find -lvirt"

Ian Jackson writes ("Likely build race, "/usr/bin/ld: cannot find -lvirt""): > tl;dr: > > I think there is a bug in libvirt's build system which, with > low probability, causes a build failure containing this message: > /usr/bin/ld: cannot find -lvirt > > Complete build logs of two attempts: >

Re: [Xen-devel] [PATCH 3/9] x86/vmx: Factor locate_msr_entry() out of vmx_find_msr() and vmx_add_msr()

On Wed, May 23, 2018 at 05:55:50PM +0100, Andrew Cooper wrote: > On 23/05/18 17:39, Roger Pau Monné wrote: > > On Tue, May 22, 2018 at 12:20:40PM +0100, Andrew Cooper wrote: > >> Instead of having multiple algorithms searching the MSR lists, implement a > >> single one. It has the semantics

Re: [Xen-devel] [PATCH 3/9] x86/vmx: Factor locate_msr_entry() out of vmx_find_msr() and vmx_add_msr()

On 24/05/18 11:53, Roger Pau Monné wrote: > On Wed, May 23, 2018 at 05:55:50PM +0100, Andrew Cooper wrote: >> On 23/05/18 17:39, Roger Pau Monné wrote: >>> On Tue, May 22, 2018 at 12:20:40PM +0100, Andrew Cooper wrote: Instead of having multiple algorithms searching the MSR lists, implement a

[Xen-devel] [xen-4.7-testing test] 123066: regressions - FAIL

flight 123066 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/123066/ 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.

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

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. > > Position Independent Executable (PIE) support will allow to extended the > KASLR randomization range below the -2G memory limit. > >

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

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. > > Position Independent Executable (PIE) support will allow to extended the > KASLR randomization range below the -2G memory limit. What

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

On Wed 23-05-18 16:07:16, Huaisheng HS1 Ye wrote: > From: Michal Hocko [mailto:mho...@kernel.org] > Sent: Wednesday, May 23, 2018 2:37 AM > > > > On Mon 21-05-18 23:20:21, Huaisheng Ye wrote: > > > From: Huaisheng Ye > > > > > > Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with

Re: [Xen-devel] Test for osstest, features used in Qubes OS

>>> On 23.05.18 at 00:21, wrote: > I have done some more testing in the meantime. The issue also affect > 4.10.1, but not 4.10.0. That's useful since it makes the bisect shorter. > A bisect identifies 8462c575d9 "x86/xpti: Hide almost all of .text and > all

[Xen-devel] [linux-4.14 test] 123073: regressions - FAIL

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

Re: [Xen-devel] Xen Project Security Whitepaper v1 is ready for community review

>>> On 24.05.18 at 16:14, wrote: > How many bug-fixes vs. XSAs are typically in a stable branch? I was under > the impression that historically, the vast majority used to be XSAs with very > few backports. > However, this year this has really changed because Spectre and

Re: [Xen-devel] [PATCH 5/9] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

On Tue, May 22, 2018 at 12:20:42PM +0100, Andrew Cooper wrote: > Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen > updates a host MSR load list entry with the current hardware value of > MSR_DEBUGCTL. This is wrong. > > On VMExit, hardware automatically resets

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

On 24/05/18 15:14, Simon Gaiser wrote: > Jan Beulich: > On 24.05.18 at 16:00, wrote: >>> Jan Beulich: In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") I've failed to remember the fact that multiple CPUs share a stub mapping

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

>>> On 24.05.18 at 16:24, wrote: > On 24/05/18 15:22, Jan Beulich wrote: > On 24.05.18 at 16:18, wrote: >>> Can you try with the "x86/traps: Dump the instruction stream even for >>> double faults" patch I've just posted, and show the full

Re: [Xen-devel] Test for osstest, features used in Qubes OS

Jan Beulich: On 23.05.18 at 00:21, wrote: >> I have done some more testing in the meantime. The issue also affect >> 4.10.1, but not 4.10.0. That's useful since it makes the bisect shorter. >> A bisect identifies 8462c575d9 "x86/xpti: Hide almost all of .text

Re: [Xen-devel] Xen Project Security Whitepaper v1 is ready for community review

>>> On 24.05.18 at 15:50, wrote: > > On 24/05/2018, 01:48, "Steven Haigh" wrote: > > On 2018-05-22 20:52, Steven Haigh wrote: > > On Tuesday, 22 May 2018 8:11:38 PM AEST Jan Beulich wrote: > >> >>> On 18.05.18 at 19:53,

Re: [Xen-devel] [PATCH for-4.11] x86/traps: Dump the instruction stream even for double faults

>>> On 24.05.18 at 16:07, wrote: > This helps debug #DF's which occur in alternative patches > > Reported-by: George Dunlap > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich

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

Andrew Cooper: > On 24/05/18 15:14, Simon Gaiser wrote: >> Jan Beulich: >> On 24.05.18 at 16:00, wrote: Jan Beulich: > In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") > I've failed to remember the fact that multiple CPUs share

Re: [Xen-devel] Xen Project Security Whitepaper v1 is ready for community review

On 24/05/2018, 01:48, "Steven Haigh" wrote: On 2018-05-22 20:52, Steven Haigh wrote: > On Tuesday, 22 May 2018 8:11:38 PM AEST Jan Beulich wrote: >> >>> On 18.05.18 at 19:53, wrote: >> > Alternative workaround for this would

Re: [Xen-devel] Xen Project Security Whitepaper v1 is ready for community review

On 24/05/2018, 10:00, "Jan Beulich" wrote: >>> On 24.05.18 at 15:50, wrote: > > On 24/05/2018, 01:48, "Steven Haigh" wrote: > > On 2018-05-22 20:52, Steven Haigh wrote: > > On Tuesday, 22 May

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

On 24/05/18 15:35, Simon Gaiser wrote: > Andrew Cooper: >> On 24/05/18 15:14, Simon Gaiser wrote: >>> Jan Beulich: >>> On 24.05.18 at 16:00, wrote: > Jan Beulich: >> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") >> I've failed

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

On Wed 23-05-18 22:19:19, Matthew Wilcox wrote: > On Tue, May 22, 2018 at 08:37:28PM +0200, Michal Hocko wrote: > > So why is this any better than the current code. Sure I am not a great > > fan of GFP_ZONE_TABLE because of how it is incomprehensible but this > > doesn't look too much better, yet

Re: [Xen-devel] [PATCH] block drivers/block: Use octal not symbolic permissions

On 5/23/18 4:35 PM, Joe Perches wrote: > On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote: >> On 5/23/18 2:05 PM, Joe Perches wrote: >>> Convert the S_ symbolic permissions to their octal equivalents as >>> using octal and not symbolic permissions is preferred by many as more >>> readable. >>>

Re: [Xen-devel] [PATCH] arm: Coverity 1469342 correct find_*_bit() functions use

Hi Artem, Thank you for the report. On 24/05/18 14:20, Artem Mygaiev wrote: vgic_vcpu_pending_irq() uses find_next_bit() library function with single 'unsigned long' variable, while it is designed to work with memory regions. Nothing wrong is happening since 'offset' is set to 0 (other

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

On 24/05/18 14:41, Jan Beulich wrote: > In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") > I've failed to remember the fact that multiple CPUs share a stub > mapping page. Therefore it is wrong to unconditionally zap the mapping > when bringing down a CPU; it may only be

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

>>> On 24.05.18 at 15:48, wrote: > On 24/05/18 14:41, Jan Beulich wrote: >> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") >> I've failed to remember the fact that multiple CPUs share a stub >> mapping page. Therefore it is wrong to

Re: [Xen-devel] [PATCH 5/9] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

On 24/05/18 13:14, Roger Pau Monné wrote: > On Tue, May 22, 2018 at 12:20:42PM +0100, Andrew Cooper wrote: >> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen >> updates a host MSR load list entry with the current hardware value of >> MSR_DEBUGCTL. This is wrong. >> >> On

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

In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") I've failed to remember the fact that multiple CPUs share a stub mapping page. Therefore it is wrong to unconditionally zap the mapping when bringing down a CPU; it may only be unmapped when no other online CPU uses that same

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

>>> On 24.05.18 at 16:00, wrote: > Jan Beulich: >> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") >> I've failed to remember the fact that multiple CPUs share a stub >> mapping page. Therefore it is wrong to unconditionally zap the mapping >>

Re: [Xen-devel] [PATCH] arm: Coverity 1469342 correct find_*_bit() functions use

Hi Julien On 24.05.18 16:49, Julien Grall wrote: Hi Artem, Thank you for the report. On 24/05/18 14:20, Artem Mygaiev wrote: vgic_vcpu_pending_irq() uses find_next_bit() library function with single 'unsigned long' variable, while it is designed to work with memory regions. Nothing wrong is

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

On 24/05/18 15:22, Jan Beulich wrote: On 24.05.18 at 16:18, wrote: >> Can you try with the "x86/traps: Dump the instruction stream even for >> double faults" patch I've just posted, and show the full #DF panic log >> please? (Its conceivable that there are

Re: [Xen-devel] [PATCH 2/9] x86/vmx: Internal cleanup for MSR load/save infrastructure

>>> On 22.05.18 at 13:20, wrote: > --- a/xen/arch/x86/hvm/vmx/vmcs.c > +++ b/xen/arch/x86/hvm/vmx/vmcs.c > @@ -1292,48 +1292,50 @@ static int vmx_msr_entry_key_cmp(const void *key, > const void *elt) > struct vmx_msr_entry *vmx_find_msr(uint32_t msr, enum

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

On Thu, May 24, 2018 at 02:23:23PM +0200, Michal Hocko wrote: > > If we had eight ZONEs, we could offer: > > No, please no more zones. What we have is quite a maint. burden on its > own. Ideally we should only have lowmem, highmem and special/device > zones for directly kernel accessible memory,

Re: [Xen-devel] [PATCH 5/9] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

>>> On 22.05.18 at 13:20, wrote: > Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen > updates a host MSR load list entry with the current hardware value of > MSR_DEBUGCTL. This is wrong. > > On VMExit, hardware automatically resets

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

On Thu 24-05-18 08:18:18, Matthew Wilcox wrote: > On Thu, May 24, 2018 at 02:23:23PM +0200, Michal Hocko wrote: > > > If we had eight ZONEs, we could offer: > > > > No, please no more zones. What we have is quite a maint. burden on its > > own. Ideally we should only have lowmem, highmem and

Re: [Xen-devel] [PATCH 8/9] x86/vmx: Support removing MSRs from the host/guest load/save lists

On Tue, May 22, 2018 at 12:20:45PM +0100, Andrew Cooper wrote: > Up until this point, the MSR load/save lists have only ever accumulated > content. Introduce vmx_del_msr() as a companion to vmx_add_msr(). > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich

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

On Tue, May 22, 2018 at 12:20:46PM +0100, 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

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

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 more will come. No functional change. Signed-off-by: Wei Liu --- Cc: Jan Beulich Cc:

[Xen-devel] [PATCH 0/5] Share CPUID stuff between hypervisor and toolstack

The hypervisor has some nice objects and definitions that toolstack can use, too. Make that happen. The anticipation is in the future MSR objects and definitions should be shared, too. Cc: Ian Jackson Cc: Jan Beulich Cc: Andrew Cooper

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

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. Signed-off-by: Wei Liu --- Cc: Jan Beulich

[Xen-devel] [PATCH 5/5] XXX DO NOT APPLY: compilation test

--- tools/libxc/xc_cpuid_x86.c | 17 + 1 file changed, 17 insertions(+) diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c index 89ded718bc..0af04a4e5a 100644 --- a/tools/libxc/xc_cpuid_x86.c +++ b/tools/libxc/xc_cpuid_x86.c @@ -869,3 +869,20 @@ int

[Xen-devel] [PATCH 4/5] libxc: introduce xc_cpuid_x86.h

Collect cpuid related things into a header file. Provide the necessary macros to make it work. Signed-off-by: Wei Liu --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Ian Jackson ---

Re: [Xen-devel] [PATCH 4/9] x86/vmx: Support remote access to the MSR lists

>>> On 22.05.18 at 13:20, wrote: > @@ -537,25 +544,27 @@ enum vmx_msr_list_type { > VMX_MSR_GUEST, > }; > > -int vmx_add_msr(uint32_t msr, enum vmx_msr_list_type type); > +int vmx_add_msr(struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type); > > -static

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

Andrew Cooper: > On 24/05/18 15:35, Simon Gaiser wrote: >> Andrew Cooper: >>> On 24/05/18 15:14, Simon Gaiser wrote: Jan Beulich: On 24.05.18 at 16:00, wrote: >> Jan Beulich: >>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen

[Xen-devel] [PATCH 3/5] tools: link arch-shared directory

Signed-off-by: Wei Liu --- Cc: Ian Jackson --- .gitignore | 1 + tools/include/Makefile | 5 - 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index 7004349d5a..808f4f5497 100644 ---

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

Jan Beulich: On 24.05.18 at 17:10, wrote: >> Jan Beulich: >> On 24.05.18 at 16:14, wrote: Jan Beulich: On 24.05.18 at 16:00, wrote: >> Jan Beulich: >>> In commit d1d6fc97d6

Re: [Xen-devel] [PATCH 6/9] x86/vmx: Pass an MSR value into vmx_msr_add()

>>> On 22.05.18 at 13:20, wrote: > The main purpose of this change is to allow us to set a specific MSR value, > without needing to know whether there is already a load/save list slot for > it. > Previously, callers wanting this property needed to call both

Re: [Xen-devel] [PATCH v2] arm: clean-up: correct find_*_bit() functions use

Hi Artem, Title: It would be good to specify the subsystem you modify. arm: vgic: ... On 24/05/18 16:24, Artem Mygaiev wrote: vgic_vcpu_pending_irq() uses find_next_bit() library function with single 'unsigned long' variable, while it is designed to work with memory regions and offsets. It

[Xen-devel] [linux-4.9 test] 123074: regressions - FAIL

flight 123074 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/123074/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvhv2-amd 7 xen-bootfail REGR. vs. 122969

Re: [Xen-devel] [PATCH 8/9] x86/vmx: Support removing MSRs from the host/guest load/save lists

On 24/05/18 16:42, Roger Pau Monné wrote: > On Tue, May 22, 2018 at 12:20:45PM +0100, Andrew Cooper wrote: >> Up until this point, the MSR load/save lists have only ever accumulated >> content. Introduce vmx_del_msr() as a companion to vmx_add_msr(). >> >> Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH 5/9] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

On 24/05/18 16:08, Jan Beulich wrote: On 22.05.18 at 13:20, wrote: >> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen >> updates a host MSR load list entry with the current hardware value of >> MSR_DEBUGCTL. This is wrong. >> >> On

Re: [Xen-devel] [PATCH 7/9] x86/vmx: Support load-only guest MSR list entries

>>> On 22.05.18 at 13:20, wrote: > Currently, the VMX_MSR_GUEST type maintains completely symmetric guest load > and save lists, by pointing VM_EXIT_MSR_STORE_ADDR and > VM_ENTRY_MSR_LOAD_ADDR > at the same page, and setting VM_EXIT_MSR_STORE_COUNT and >

[Xen-devel] [PATCH v2] arm: clean-up: correct find_*_bit() functions use

vgic_vcpu_pending_irq() uses find_next_bit() library function with single 'unsigned long' variable, while it is designed to work with memory regions and offsets. It would be more correct to use the find_first_bit() function instead. Signed-off-by: Artem Mygaiev diff

Re: [Xen-devel] [PATCH 7/9] x86/vmx: Support load-only guest MSR list entries

On Tue, May 22, 2018 at 12:20:44PM +0100, Andrew Cooper wrote: > Currently, the VMX_MSR_GUEST type maintains completely symmetric guest load > and save lists, by pointing VM_EXIT_MSR_STORE_ADDR and VM_ENTRY_MSR_LOAD_ADDR > at the same page, and setting VM_EXIT_MSR_STORE_COUNT and >

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

>>> On 24.05.18 at 17:10, wrote: > Jan Beulich: > On 24.05.18 at 16:14, wrote: >>> Jan Beulich: >>> On 24.05.18 at 16:00, wrote: > Jan Beulich: >> In commit d1d6fc97d6 ("x86/xpti: really

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

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. > > > > Position Independent Executable (PIE) support will allow

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

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 have decided not > to expose it (for whatever [questionable?]

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

Jan Beulich: On 24.05.18 at 16:14, wrote: >> Jan Beulich: >> On 24.05.18 at 16:00, wrote: Jan Beulich: > In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") > I've failed to remember the fact

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

> On May 24, 2018, at 3:53 PM, Andrew Cooper wrote: > > On 24/05/18 15:35, Simon Gaiser wrote: >> Andrew Cooper: >>> On 24/05/18 15:14, Simon Gaiser wrote: Jan Beulich: On 24.05.18 at 16:00, wrote: >> Jan Beulich:

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

>>> On 24.05.18 at 17:10, wrote: > Jan Beulich: > On 24.05.18 at 16:14, wrote: >>> Jan Beulich: >>> On 24.05.18 at 16:00, wrote: > Jan Beulich: >> In commit d1d6fc97d6 ("x86/xpti: really

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

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. > > > > Position Independent Executable (PIE) support will allow

Re: [Xen-devel] [PATCH v2] arm: clean-up: correct find_*_bit() functions use

On Thu, 24 May 2018, Julien Grall wrote: > Hi Artem, > > Title: It would be good to specify the subsystem you modify. > > arm: vgic: ... > > On 24/05/18 16:24, Artem Mygaiev wrote: > > vgic_vcpu_pending_irq() uses find_next_bit() library function with single > > 'unsigned long' variable, while

Re: [Xen-devel] [PATCH] block drivers/block: Use octal not symbolic permissions

On 5/24/18 7:01 AM, Joe Perches wrote: > On Thu, 2018-05-24 at 06:47 -0600, Jens Axboe wrote: >> On 5/23/18 4:35 PM, Joe Perches wrote: >>> On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote: On 5/23/18 2:05 PM, Joe Perches wrote: > Convert the S_ symbolic permissions to their octal

Re: [Xen-devel] [PATCH v2 10/10] xen: add cloc target

On Thu, 24 May 2018, Jan Beulich wrote: > >>> On 23.05.18 at 20:21, wrote: > > On Wed, 23 May 2018, Jan Beulich wrote: > >> >>> On 22.05.18 at 22:08, wrote: > >> > On Tue, 22 May 2018, Jan Beulich wrote: > >> >> >>> On 22.05.18 at 02:53,

Re: [Xen-devel] [PATCH 13/13] xen/arm: Avoid to use current everywhere in enter_hypervisor_head

On Thu, 24 May 2018, Julien Grall wrote: > Hi Stefano, > > On 24/05/18 00:47, Stefano Stabellini wrote: > > On Tue, 22 May 2018, Julien Grall wrote: > > > Using current is fairly expensive, so save up into a variable. > > > > > > Signed-off-by: Julien Grall > > > > Good

[Xen-devel] [PATCH for-4.11] x86/traps: Dump the instruction stream even for double faults

This helps debug #DF's which occur in alternative patches Reported-by: George Dunlap Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Juergen Gross --- xen/arch/x86/traps.c| 2 +-

Re: [Xen-devel] [PATCH] arm: Coverity 1469342 correct find_*_bit() functions use

On 24/05/18 15:07, Artem Mygaiev wrote: Hi Julien Hi Artem, On 24.05.18 16:49, Julien Grall wrote: Hi Artem, Thank you for the report. On 24/05/18 14:20, Artem Mygaiev wrote: vgic_vcpu_pending_irq() uses find_next_bit() library function with single 'unsigned long' variable, while it

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

>>> On 24.05.18 at 16:14, wrote: > Jan Beulich: > On 24.05.18 at 16:00, wrote: >>> Jan Beulich: In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") I've failed to remember the fact that multiple CPUs

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

Hi, This series implements a new xl config entry. Users can use the new config entry to statically setup shared memory areas among VMs that don't have grant table support so that they could communicate with each other through the static shared memory areas. It was originally developed by

[Xen-devel] [PATCH v5 1/6] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

From: Zhongze Liu Author: Zhongze Liu The existing XENMAPSPACE_gmfn_foreign subop of XENMEM_add_to_physmap forbids a Dom0 to map memory pages from one DomU to another, which restricts some useful yet not dangerous use cases -- such as sharing pages

[Xen-devel] xsa263 wont apply

Hi there 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 considered suitable/safe to rebase to for packaging purposes?

[Xen-devel] [PATCH v5 6/6] docs: documentation about static shared memory regions

From: Zhongze Liu Author: Zhongze Liu Add docs to document the motivation, usage, use cases and other relevant information about the static shared memory feature. This is for the proposal "Allow setting up shared memory areas between VMs from xl

[Xen-devel] [PATCH v5 2/6] libxl: introduce a new structure to represent static shared memory regions

From: Zhongze Liu Author: Zhongze Liu Add a new structure to the IDL family to represent static shared memory regions as proposed in the proposal "Allow setting up shared memory areas between VMs from xl config file" (see [1]). And deleted some

[Xen-devel] [PATCH v5 3/6] libxl: support mapping static shared memory areas during domain creation

From: Zhongze Liu Author: Zhongze Liu Add libxl__sshm_add to map shared pages from one DomU to another, The mapping process involves the following steps: * Set defaults and check for further errors in the static_shm configs: overlapping areas,

[Xen-devel] [PATCH v5 5/6] libxl:xl: add parsing code to parse "libxl_static_sshm" from xl config files

From: Zhongze Liu Author: Zhongze Liu Add the parsing utils for the newly introduced libxl_static_sshm struct to the libxl/libxlu_* family. And add realated parsing code in xl to parse the struct from xl config files. This is for the proposal "Allow

[Xen-devel] [PATCH v5 4/6] libxl: support unmapping static shared memory areas during domain destruction

From: Zhongze Liu Author: Zhongze Liu Add libxl__sshm_del to unmap static shared memory areas mapped by libxl__sshm_add during domain creation. The unmapping process is: * For a master: decrease the refcount of the sshm region, if the refcount

Re: [Xen-devel] [PATCH 3/9] x86/vmx: Factor locate_msr_entry() out of vmx_find_msr() and vmx_add_msr()

On Thu, May 24, 2018 at 11:59:07AM +0100, Andrew Cooper wrote: > On 24/05/18 11:53, Roger Pau Monné wrote: > > On Wed, May 23, 2018 at 05:55:50PM +0100, Andrew Cooper wrote: > >> On 23/05/18 17:39, Roger Pau Monné wrote: > >>> On Tue, May 22, 2018 at 12:20:40PM +0100, Andrew Cooper wrote: >

Re: [Xen-devel] [PULL v2 00/15] xen-20180522-tag

On 22 May 2018 at 19:46, Stefano Stabellini wrote: > The following changes since commit d32e41a1188e929cc0fb16829ce3736046951e39: > > Merge remote-tracking branch > 'remotes/famz/tags/docker-and-block-pull-request' into staging (2018-05-18 > 14:11:52 +0100) > > are

Re: [Xen-devel] [PATCH] block drivers/block: Use octal not symbolic permissions

On Thu, 2018-05-24 at 06:47 -0600, Jens Axboe wrote: > On 5/23/18 4:35 PM, Joe Perches wrote: > > On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote: > > > On 5/23/18 2:05 PM, Joe Perches wrote: > > > > Convert the S_ symbolic permissions to their octal equivalents as > > > > using octal and not

Re: [Xen-devel] [PATCH 5/9] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

>>> On 24.05.18 at 14:39, wrote: > On 24/05/18 13:14, Roger Pau Monné wrote: >> On Tue, May 22, 2018 at 12:20:42PM +0100, Andrew Cooper wrote: >>> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen >>> updates a host MSR load list entry with the

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

Jan Beulich: On 24.05.18 at 16:00, wrote: >> Jan Beulich: >>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") >>> I've failed to remember the fact that multiple CPUs share a stub >>> mapping page. Therefore it is wrong to unconditionally

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

Can you please point out the specific instances? This patch is no different than the last v1 patch. I have just added tasklets to it. On 05/23/2018 10:48 PM, Manish Jaggi wrote: Hi Sameer, General Comment, please use appropriate variable names for XXX_domain structures in code which is xen

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

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 have mostly just changed variable names. The macro is self explanatory.

Re: [Xen-devel] [PATCH v3 21/27] x86/ftrace: Adapt function tracing for PIE support

On Thu, 24 May 2018 13:40:24 +0200 Petr Mladek wrote: > On Wed 2018-05-23 12:54:15, Thomas Garnier wrote: > > When using -fPIE/PIC with function tracing, the compiler generates a > > call through the GOT (call *__fentry__@GOTPCREL). This instruction > > takes 6 bytes instead of

[Xen-devel] [qemu-mainline test] 123075: regressions - FAIL

flight 123075 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/123075/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 122357

Re: [Xen-devel] [PATCH v3 21/27] x86/ftrace: Adapt function tracing for PIE support

On Thu, May 24, 2018 at 1:16 PM Steven Rostedt wrote: > On Thu, 24 May 2018 13:40:24 +0200 > Petr Mladek wrote: > > On Wed 2018-05-23 12:54:15, Thomas Garnier wrote: > > > When using -fPIE/PIC with function tracing, the compiler generates a > > > call

  1   2   >