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 tmpfile := $(shell mktemp)) >> >> > + $(foreach f, $(shell find $(BASEDI

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

>>> 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 this location. Independent of that I'd prefer if new files used hyphens instead of underscores in their names - just like for command l

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_ prefix? Jan _

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 as to Stefano the other d

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 ar

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 but without IBRSB, nor is ther

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 (0) > #define WARN_ON(p)

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

Hi Jan, On 24/05/18 08:59, Jan Beulich wrote: 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

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 > KASL

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

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 cases where the user decides that they'd rather not get a tr

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 b

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 repu

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. There is not a >> processo

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 to simply so we >>> don't give the guest implausible con

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 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 am not going to ask you

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 requir

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. vs.

[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 u

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] [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. > > S

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

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 5 on the usual relative call. > > If PIE is enabled, replace the 6th byte of the

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

On Tue, May 22, 2018 at 12:20:41PM +0100, Andrew Cooper wrote: > At the moment, all modifications of the MSR lists are in current context. > However, future changes may need to put MSR_EFER into the lists from domctl > hypercall context. > > Plumb a struct vcpu parameter down through the infrastru

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

On 24/05/18 12:50, Roger Pau Monné wrote: > On Tue, May 22, 2018 at 12:20:41PM +0100, Andrew Cooper wrote: >> At the moment, all modifications of the MSR lists are in current context. >> However, future changes may need to put MSR_EFER into the lists from domctl >> hypercall context. >> >> Plumb a

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 MSR_DEBUGC

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: > In

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 encoded zone number. >

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 w

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 available in the git reposit

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

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] 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 s

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 .data/.rodata/.bss mappings" as the comm

[Xen-devel] [PATCH] arm: Coverity 1469342 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. Nothing wrong is happening since 'offset' is set to 0 (other values could lead to memory corruption), but it would be more correct to use the fin

[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] 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 and >> all .data/.rodata/.bss map

[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 pa

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 unmap

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 values

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 be more frequent point releases by >> > default

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 current hardware value of >>>

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, wrote: > >> > Alternative workaround for this would be m

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 unconditionally zap the mapping >> when b

[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 +- xen/arch/x86/x86_64/traps.c | 1 + xen/include/asm-x86/processor.h | 1 + 3 files changed, 3

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 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 >> when bringing down a CPU; it ma

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 zap the mapping >>> when bringin

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 2018 8:11:38 PM AEST Jan Beulich wrote: > >> >>> On 1

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 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://

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 page. Therefore it is wrong to un

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 Meltdown > related fixes

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 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 multiple different issues here.) >

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 share a stub mapping page. Therefore it is wrong to uncondi

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 #DF panic log >>> please? (Its conceivable that there

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 a stub > mapping page. Ther

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 to remember the fact that mult

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 vmx_msr_list_type type) > { > stru

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 that multiple CPUs share a stub > mapping page. Therefore it

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: >>> In commit d1d6fc97d6 ("x86/xpti: really hide almost al

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 vmx_add_*_msr() > and vmx_write_*_msr()

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 inline int vmx_add_host_load

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 image") >>> I've failed to rem

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, t

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

>>> 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 multiple different issues here.) Well, as long as we're on a guest kernel st

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

Hi, On 24.05.18 17:22, Julien Grall wrote: 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

[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 --git a/xen/arch/arm/gic-

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 MSR_DEBUGCTL to 0. I'm pretty certain

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 speci

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 hide almost all of Xen image") >> I've failed to remember the fact that multiple CPUs sha

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 wo

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 > VM_ENTRY_MSR_LOA

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 > CC: Jun Nakajima > CC: Kevin T

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 >> --- >> C

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 hide almost all of Xen image") >> I've failed to remember the fact that multiple CPUs sha

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 VMExit, hardware automatically res

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 vmx_update_g

[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 Wei Liu (5): x86: move definition of struct cpuid_leaf t

[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 Cc: Andrew Cooper --- tools/tests/x

[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 xc_cpuid_set(

[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: Andrew Cooper Any suggestion on the direc

[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 --- tools/libxc/xc_cpuid_x86.c | 6 +- tools/libxc/xc_cpuid_x86.h | 16 2 files changed, 17 inserti

[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 --- a/.gitignore +++ b/.gitignore @@ -198,6 +198,7 @@ tools/hot

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 ("x86/xpti: really hide almost all of Xen image") >>> I've failed to remember the fact t

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 > VM_ENTRY_MSR_LOAD_COUNT to the same value.

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 to extended the

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 to extended the

[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?] reason

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

On 24/05/18 17:01, Roger Pau Monné wrote: > 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

[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 test-amd64-amd64-xl-q

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, wrote: > >> >> > + $(eval tmpfile := $(shell mktemp))

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 idea. I am curious to kn

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 i

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 equiv

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 5 on the usual rel

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 s

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. Should I just change t

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

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 this location. As explained previously this header can be used for the any driver that we want

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

On 05/24/2018 01:58 AM, Jan Beulich wrote: 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_ prefix? I'll fix

  1   2   >