Re: [Xen-devel] Ping: [PATCH v2] build: provide option to disambiguate symbol names

On 20.11.2019 18:13, Andrew Cooper wrote: > On 20/11/2019 16:40, Jürgen Groß wrote: >> On 20.11.19 17:30, Jan Beulich wrote: >>> On 08.11.2019 12:18, Jan Beulich wrote: The .file assembler directives generated by the compiler do not include any path components (gcc) or just the ones speci

Re: [Xen-devel] Status of 4.13

On 21.11.2019 08:36, Jürgen Groß wrote: > On 21.11.19 08:30, Steven Haigh wrote: >> On 2019-11-21 17:05, Jürgen Groß wrote: >>> Where do we stand with Xen 4.13 regarding blockers and related patches? >>> >>> 2. Ryzen/Rome failures with Windows guests: >>>    What is the currently planned way to add

Re: [Xen-devel] Status of 4.13

On 21.11.2019 07:05, Jürgen Groß wrote: > Where do we stand with Xen 4.13 regarding blockers and related patches? > > 1. OSStest failure regarding nested test: > I'm not quite sure whether the currently debated patch of Andrew is > fixing the problem. If not, do we know what is missing or

Re: [Xen-devel] [PATCH v2 1/2] introduce GFN notification for translated domains

On 20.11.2019 21:22, Julien Grall wrote: > On 14/11/2019 16:43, Jan Beulich wrote: >> In order for individual IOMMU drivers (and from an abstract pov also >> architectures) to be able to adjust, ahead of actual mapping requests, >> their data structures when they might cover only a sub-range of all

Re: [Xen-devel] [RFC 7/7] arm/gic-v3: add GIC version suffix to iomem range variables

Hello Stefano, I suppose, in the discussion with ARM, it might be useful to come with existing support case numbers. Here they are: Case ID. sort descending Status. sort descending

Re: [Xen-devel] [PATCH for-4.13] x86/vlapic: allow setting APIC_SPIV_FOCUS_DISABLED in x2APIC mode

On Wed, Nov 20, 2019 at 06:39:20PM +0100, Roger Pau Monne wrote: > case APIC_SPIV: > if ( msr_content & ~(APIC_VECTOR_MASK | APIC_SPIV_APIC_ENABLED | > + /* > + * APIC_SPIV_FOCUS_DISABLED is not supported on s/not supported/res

Re: [Xen-devel] Status of 4.13

On Thu, Nov 21, 2019 at 09:53:44AM +0100, Jan Beulich wrote: > On 21.11.2019 07:05, Jürgen Groß wrote: > > Where do we stand with Xen 4.13 regarding blockers and related patches? > > > > 1. OSStest failure regarding nested test: > > I'm not quite sure whether the currently debated patch of And

Re: [Xen-devel] [PATCH for-4.13] x86/vmx: always sync PIR to IRR before vmentry

On Mon, Nov 18, 2019 at 05:00:29PM +0100, Jan Beulich wrote: > On 18.11.2019 15:20, Roger Pau Monné wrote: > > On Mon, Nov 18, 2019 at 03:00:00PM +0100, Jan Beulich wrote: > >> On 18.11.2019 14:46, Roger Pau Monné wrote: > >>> On Mon, Nov 18, 2019 at 01:01:58PM +0100, Jan Beulich wrote: > On

Re: [Xen-devel] [PATCH v1 1/2] x86/cpu: maintain a parked CPU bitmap

Hi, On 20/11/2019 23:05, Chao Gao wrote: It helps to distinguish parked CPUs from those are really offlined or hot-added. We need to know the parked CPUs in order to do a special check against them to ensure that all CPUs, except those are really offlined or hot-added, have the same ucode versio

Re: [Xen-devel] [PATCH for-4.13] x86/vlapic: allow setting APIC_SPIV_FOCUS_DISABLED in x2APIC mode

On 20.11.2019 18:39, Roger Pau Monne wrote: > Current code unconditionally prevents setting APIC_SPIV_FOCUS_DISABLED > regardless of the processor model, which is not correct according to > the specification. > > Fix it by allowing setting APIC_SPIV_FOCUS_DISABLED based on the > domain cpuid polic

Re: [Xen-devel] [PATCH v1 1/2] x86/cpu: maintain a parked CPU bitmap

On 21.11.2019 10:47, Julien Grall wrote: > On 20/11/2019 23:05, Chao Gao wrote: >> --- a/xen/arch/arm/smpboot.c >> +++ b/xen/arch/arm/smpboot.c >> @@ -39,6 +39,7 @@ >> cpumask_t cpu_online_map; >> cpumask_t cpu_present_map; >> cpumask_t cpu_possible_map; >> +cpumask_var_t cpu_parked_map; > >

Re: [Xen-devel] [PATCH v1 1/2] x86/cpu: maintain a parked CPU bitmap

On 21.11.2019 00:05, Chao Gao wrote: > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -337,7 +337,11 @@ void __init early_cpu_init(void) > } > > if (!(c->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON))) > + { > park_offline_cpus = opt_mce; >

Re: [Xen-devel] [PATCH for-4.13] x86/vlapic: allow setting APIC_SPIV_FOCUS_DISABLED in x2APIC mode

On Thu, Nov 21, 2019 at 10:48:16AM +0100, Jan Beulich wrote: > On 20.11.2019 18:39, Roger Pau Monne wrote: > > Current code unconditionally prevents setting APIC_SPIV_FOCUS_DISABLED > > regardless of the processor model, which is not correct according to > > the specification. > > > > Fix it by al

Re: [Xen-devel] [PATCH v2 1/2] introduce GFN notification for translated domains

On 21/11/2019 09:04, Jan Beulich wrote: On 20.11.2019 21:22, Julien Grall wrote: On 14/11/2019 16:43, Jan Beulich wrote: In order for individual IOMMU drivers (and from an abstract pov also architectures) to be able to adjust, ahead of actual mapping requests, their data structures when they

[Xen-devel] [PATCH for-4.13 v2] x86/vlapic: allow setting APIC_SPIV_FOCUS_DISABLED in x2APIC mode

Current code unconditionally prevents setting APIC_SPIV_FOCUS_DISABLED regardless of the processor model, which is not correct according to the specification. This issue was discovered while trying to boot a pvshim with x2APIC enabled. Always allow setting APIC_SPIV_FOCUS_DISABLED: the local APIC

Re: [Xen-devel] [PATCH v1 2/2] microcode: reject late ucode loading if any core is parked

On 21.11.2019 00:05, Chao Gao wrote: > If a core with all of its thread being parked, late ucode loading > which currently only loads ucode on online threads would lead to > differing ucode revisions in the system. In general, keeping ucode > revision consistent would be less error-prone. To this e

Re: [Xen-devel] [PATCH for-4.13 v2] x86/vlapic: allow setting APIC_SPIV_FOCUS_DISABLED in x2APIC mode

On 21.11.2019 11:19, Roger Pau Monne wrote: > Current code unconditionally prevents setting APIC_SPIV_FOCUS_DISABLED > regardless of the processor model, which is not correct according to > the specification. > > This issue was discovered while trying to boot a pvshim with x2APIC > enabled. > > A

[Xen-devel] [xen-4.12-testing test] 144228: regressions - FAIL

flight 144228 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/144228/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 144035 Tests

Re: [Xen-devel] [PATCH for-4.13 v2] x86/vlapic: allow setting APIC_SPIV_FOCUS_DISABLED in x2APIC mode

On 21.11.19 11:19, Roger Pau Monne wrote: Current code unconditionally prevents setting APIC_SPIV_FOCUS_DISABLED regardless of the processor model, which is not correct according to the specification. This issue was discovered while trying to boot a pvshim with x2APIC enabled. Always allow sett

Re: [Xen-devel] [PATCH v2 1/2] introduce GFN notification for translated domains

On 21.11.2019 11:07, Julien Grall wrote: > > > On 21/11/2019 09:04, Jan Beulich wrote: >> On 20.11.2019 21:22, Julien Grall wrote: >>> On 14/11/2019 16:43, Jan Beulich wrote: TBD: Does Arm actually have anything to check against in its arch_notify_gfn()? >>> >>> I understand that

Re: [Xen-devel] Status of 4.13

On Thu, 21 Nov 2019 at 06:05, Jürgen Groß wrote: [...] > 4. Are there any blockers for 4.13 other than 1. and 2. (apart of any > pending XSAs)? > FWIW I've pushed all the toolstack patches that I'm aware of. Wei. > > Juergen ___ Xen-devel mailing

Re: [Xen-devel] [PATCH v1 1/2] x86/cpu: maintain a parked CPU bitmap

On Thu, Nov 21, 2019 at 11:02:10AM +0100, Jan Beulich wrote: >On 21.11.2019 10:47, Julien Grall wrote: >> On 20/11/2019 23:05, Chao Gao wrote: >>> --- a/xen/arch/arm/smpboot.c >>> +++ b/xen/arch/arm/smpboot.c >>> @@ -39,6 +39,7 @@ >>> cpumask_t cpu_online_map; >>> cpumask_t cpu_present_map; >>>

Re: [Xen-devel] [PATCH v1 2/2] microcode: reject late ucode loading if any core is parked

On Thu, Nov 21, 2019 at 11:21:13AM +0100, Jan Beulich wrote: >On 21.11.2019 00:05, Chao Gao wrote: >> If a core with all of its thread being parked, late ucode loading >> which currently only loads ucode on online threads would lead to >> differing ucode revisions in the system. In general, keeping

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

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

Re: [Xen-devel] [PATCH v1 2/2] microcode: reject late ucode loading if any core is parked

On 21.11.19 11:21, Jan Beulich wrote: On 21.11.2019 00:05, Chao Gao wrote: If a core with all of its thread being parked, late ucode loading which currently only loads ucode on online threads would lead to differing ucode revisions in the system. In general, keeping ucode revision consistent wou

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

flight 144229 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/144229/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail in 144218 pass in 144229 test-amd64-amd

Re: [Xen-devel] Xen hiding thermal capabilities from Dom0

On Tue, Nov 19, 2019 at 2:47 PM Jan Beulich wrote: > > On 19.11.2019 06:23, Rishi wrote: > > ok, thanks for clearing it up. Would a patch be accepted if this > > option of showing EAX leaf is selectively done through command line > > (default disabled)? > > In general I'd expect this to be rather

Re: [Xen-devel] Xen hiding thermal capabilities from Dom0

On Thu, Nov 21, 2019 at 07:09:31PM +0530, Rishi wrote: > On Tue, Nov 19, 2019 at 2:47 PM Jan Beulich wrote: > > > > On 19.11.2019 06:23, Rishi wrote: > > > ok, thanks for clearing it up. Would a patch be accepted if this > > > option of showing EAX leaf is selectively done through command line > >

Re: [Xen-devel] Status of 4.13

Wei Liu writes ("Re: Status of 4.13"): > FWIW I've pushed all the toolstack patches that I'm aware of. The only thing outstanding that I am aware of is [PATCH for-4.13 v1 1/2] libxl: introduce new backend type VINPUT of which I am awaiting a respin from Oleksandr Grytsov (in the To). There is a

Re: [Xen-devel] Xen hiding thermal capabilities from Dom0

On 21.11.19 14:39, Rishi wrote: On Tue, Nov 19, 2019 at 2:47 PM Jan Beulich wrote: On 19.11.2019 06:23, Rishi wrote: ok, thanks for clearing it up. Would a patch be accepted if this option of showing EAX leaf is selectively done through command line (default disabled)? In general I'd expect

Re: [Xen-devel] arm/vtimer: Physical timer emulation and the physical counter

On 11/19/2019 7:48 AM, Julien Grall wrote: > Hi, > > On 17/11/2019 22:32, Stewart Hildebrand wrote: >> CC'ing Julien's new email address > > For Xen-devel, I have filter to get in my inbox all e-mails where my > @arm.com is CCed :). > >> >> On Thursday, November 14, 2019 2:33 PM, Jeff Kubascik w

[Xen-devel] [PATCH V3 1/2] x86/altp2m: Add hypercall to set a range of sve bits

By default the sve bits are not set. This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(), to set a range of sve bits. The core function, p2m_set_suppress_ve_multi(), does not brake in case of a error and it is doing a best effort for setting the bits in the given range. A check for co

[Xen-devel] [PATCH V3 2/2] x86/mm: Make use of the default access param from xc_altp2m_create_view

At this moment the default_access param from xc_altp2m_create_view is not used. This patch assigns default_access to p2m->default_access at the time of initializing a new altp2m view. Signed-off-by: Alexandru Isaila --- CC: Jan Beulich CC: Andrew Cooper CC: Wei Liu CC: "Roger Pau Monné" CC:

Re: [Xen-devel] arm/vtimer: Physical timer emulation and the physical counter

Hi, On 21/11/2019 14:31, Jeff Kubascik wrote: On 11/19/2019 7:48 AM, Julien Grall wrote: Hi, On 17/11/2019 22:32, Stewart Hildebrand wrote: CC'ing Julien's new email address For Xen-devel, I have filter to get in my inbox all e-mails where my @arm.com is CCed :). On Thursday, November 14

Re: [Xen-devel] Status of 4.13

> On Nov 21, 2019, at 8:41 AM, Jan Beulich wrote: > > On 21.11.2019 08:36, Jürgen Groß wrote: >> On 21.11.19 08:30, Steven Haigh wrote: >>> On 2019-11-21 17:05, Jürgen Groß wrote: Where do we stand with Xen 4.13 regarding blockers and related patches? 2. Ryzen/Rome failures with

Re: [Xen-devel] [PATCH 1/3] x86/boot: Remove cached CPUID data from the trampoline

On 19/11/2019 16:44, Jan Beulich wrote: > On 19.11.2019 16:15, Andrew Cooper wrote: >> On 13/11/2019 13:29, Jan Beulich wrote: >>> On 13.11.2019 14:22, Andrew Cooper wrote: I am not convinced the behaviour is worth changing, and I don't have time for this scope creep. >>> There's no scope

Re: [Xen-devel] Xen hiding thermal capabilities from Dom0

On Thu, Nov 21, 2019 at 7:26 PM Roger Pau Monné wrote: > > On Thu, Nov 21, 2019 at 07:09:31PM +0530, Rishi wrote: > > On Tue, Nov 19, 2019 at 2:47 PM Jan Beulich wrote: > > > > > > On 19.11.2019 06:23, Rishi wrote: > > > > ok, thanks for clearing it up. Would a patch be accepted if this > > > > o

Re: [Xen-devel] Xen hiding thermal capabilities from Dom0

On Thu, Nov 21, 2019 at 7:54 PM Jürgen Groß wrote: > > On 21.11.19 14:39, Rishi wrote: > > On Tue, Nov 19, 2019 at 2:47 PM Jan Beulich wrote: > >> > >> On 19.11.2019 06:23, Rishi wrote: > >>> ok, thanks for clearing it up. Would a patch be accepted if this > >>> option of showing EAX leaf is sele

Re: [Xen-devel] Status of 4.13

On 21.11.2019 16:20, George Dunlap wrote: > > >> On Nov 21, 2019, at 8:41 AM, Jan Beulich wrote: >> >> On 21.11.2019 08:36, Jürgen Groß wrote: >>> On 21.11.19 08:30, Steven Haigh wrote: On 2019-11-21 17:05, Jürgen Groß wrote: > Where do we stand with Xen 4.13 regarding blockers and rela

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

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

Re: [Xen-devel] Xen hiding thermal capabilities from Dom0

On 21.11.2019 15:24, Jürgen Groß wrote: > So: no, just giving dom0 access to the management hardware isn't going > to fly. You need to have a proper virtualization layer for that purpose. Or, like I had done in our XenoLinux forward port, you need to go through hoops to make the coretemp driver ac

Re: [Xen-devel] Xen hiding thermal capabilities from Dom0

On 21.11.2019 14:39, Rishi wrote: > The reasoning to have EAX(0x06h) exposed to Dom0 is for Thermal and > Power management. I understand this. > Without EAX(0x06h) Dom0 is unable to sense presence of CPU core > temperature or do Thermal management - including but not limited to > operating Fan sp

Re: [Xen-devel] Xen hiding thermal capabilities from Dom0

On 21.11.2019 16:26, Rishi wrote: > The affected Linux driver in my case is coretemp.ko (drivers/hwmon/coretemp.c) > > It's init depends on checking presence of X86_FEATURE_DTHERM > > /* > * CPUID.06H.EAX[0] indicates whether the CPU has thermal > * sensors. We check thi

Re: [Xen-devel] Xen hiding thermal capabilities from Dom0

On Thu, Nov 21, 2019 at 08:56:41PM +0530, Rishi wrote: > On Thu, Nov 21, 2019 at 7:26 PM Roger Pau Monné wrote: > > > > On Thu, Nov 21, 2019 at 07:09:31PM +0530, Rishi wrote: > > > On Tue, Nov 19, 2019 at 2:47 PM Jan Beulich wrote: > > > > > > > > On 19.11.2019 06:23, Rishi wrote: > > > > > ok, t

Re: [Xen-devel] Xen hiding thermal capabilities from Dom0

On 21.11.19 16:36, Jan Beulich wrote: On 21.11.2019 15:24, Jürgen Groß wrote: So: no, just giving dom0 access to the management hardware isn't going to fly. You need to have a proper virtualization layer for that purpose. Or, like I had done in our XenoLinux forward port, you need to go throug

Re: [Xen-devel] arm/vtimer: Physical timer emulation and the physical counter

On 11/21/2019 10:06 AM, Julien Grall wrote:> Hi, > > On 21/11/2019 14:31, Jeff Kubascik wrote: >> On 11/19/2019 7:48 AM, Julien Grall wrote: >>> Hi, >>> >>> On 17/11/2019 22:32, Stewart Hildebrand wrote: CC'ing Julien's new email address >>> >>> For Xen-devel, I have filter to get in my inbox

Re: [Xen-devel] Xen hiding thermal capabilities from Dom0

On 21.11.2019 16:46, Jürgen Groß wrote: > On 21.11.19 16:36, Jan Beulich wrote: >> On 21.11.2019 15:24, Jürgen Groß wrote: >>> So: no, just giving dom0 access to the management hardware isn't going >>> to fly. You need to have a proper virtualization layer for that purpose. >> >> Or, like I had don

Re: [Xen-devel] Xen hiding thermal capabilities from Dom0

On 21.11.2019 16:45, Roger Pau Monné wrote: > On Thu, Nov 21, 2019 at 08:56:41PM +0530, Rishi wrote: >> On Thu, Nov 21, 2019 at 7:26 PM Roger Pau Monné wrote: >>> >>> On Thu, Nov 21, 2019 at 07:09:31PM +0530, Rishi wrote: On Tue, Nov 19, 2019 at 2:47 PM Jan Beulich wrote: > > On 19.

[Xen-devel] [PATCH 0/3] x86: enable x2APIC mode regardless of interrupt remapping support

Hello, The following series aims to allow enabling x2APIC mode without interrupt remapping support. The main usage of this would be in virtualized environments, that usually provide x2APIC support but not interrupt remapping. See the last patch for some performance numbers of using x2APIC over xA

[Xen-devel] [PATCH 2/3] x86/smp: check APIC ID on AP bringup

Check that the processor to be woken up APIC ID is addressable in the current APIC mode. Note that in practice systems with APIC IDs > 255 should already have x2APIC enabled by the firmware, and hence this is mostly a safety belt. Signed-off-by: Roger Pau Monné --- xen/arch/x86/smpboot.c | 7 ++

[Xen-devel] [PATCH 3/3] x86/apic: allow enabling x2APIC mode regardless of interrupt remapping

x2APIC mode doesn't mandate interrupt remapping, and hence can be enabled independently. This patch enables x2APIC when available, regardless of whether there's interrupt remapping support. This is beneficial specially when running on virtualized environments, since it reduces the amount of vmexit

[Xen-devel] [PATCH 1/3] x86/ioapic: only use dest32 with x2apic and interrupt remapping enabled

The IO-APIC code assumes that x2apic being enabled also implies interrupt remapping being enabled, and hence will use the 32bit destination field in the IO-APIC entry. This is safe now, but there's no reason to not enable x2APIC even without interrupt remapping, and hence the IO-APIC code needs to

Re: [Xen-devel] Status of 4.13

> On Nov 21, 2019, at 3:34 PM, Jan Beulich wrote: > > On 21.11.2019 16:20, George Dunlap wrote: >> >> >>> On Nov 21, 2019, at 8:41 AM, Jan Beulich wrote: >>> >>> On 21.11.2019 08:36, Jürgen Groß wrote: On 21.11.19 08:30, Steven Haigh wrote: > On 2019-11-21 17:05, Jürgen Groß wrote:

Re: [Xen-devel] Status of 4.13

On 21/11/2019 06:05, Jürgen Groß wrote: > Where do we stand with Xen 4.13 regarding blockers and related patches? > > 1. OSStest failure regarding nested test: >    I'm not quite sure whether the currently debated patch of Andrew is >    fixing the problem. If not, do we know what is missing or how

Re: [Xen-devel] [PATCH for-next v3 9/9] x86: introduce CONFIG_HYPERV and detection code

On Fri, Nov 15, 2019 at 03:07:29PM +0100, Jan Beulich wrote: > On 21.10.2019 17:57, Wei Liu wrote: > > --- a/xen/arch/x86/Kconfig > > +++ b/xen/arch/x86/Kconfig > > @@ -164,6 +164,15 @@ endchoice > > config GUEST > > bool > > > > +config HYPERV_GUEST > > + def_bool n > > + select GUEST >

Re: [Xen-devel] [PATCH for-next v3 5/9] x86: introduce hypervisor framework

On Fri, Nov 15, 2019 at 02:48:18PM +0100, Jan Beulich wrote: > On 21.10.2019 17:57, Wei Liu wrote: > > --- /dev/null > > +++ b/xen/arch/x86/guest/hypervisor.c > > @@ -0,0 +1,45 @@ > > +/** > > + * arch/x86/guest/hypervisor.

Re: [Xen-devel] [PATCH for-next v3 6/9] x86: rename hypervisor_{alloc, free}_unused_page

On Fri, Nov 15, 2019 at 02:49:57PM +0100, Jan Beulich wrote: > On 21.10.2019 17:57, Wei Liu wrote: > > --- a/xen/arch/x86/guest/xen/xen.c > > +++ b/xen/arch/x86/guest/xen/xen.c > > @@ -97,7 +97,7 @@ static void map_shared_info(void) > > unsigned int i; > > unsigned long rc; > > > > -

[Xen-devel] [PATCH] gnttab: make sure grant map operations don't skip their IOMMU part

Two almost simultaneous mapping requests need to make sure that at the completion of the earlier one IOMMU mappings (established explicitly here in the PV case) have been put in place. Forever since the splitting of the grant table lock a violation of this has been possible (using simplified pin co

Re: [Xen-devel] Status of 4.13

On 21.11.2019 17:20, Andrew Cooper wrote: > "xen/vcpu: Sanitise VCPUOP_initialise call hierachy".  This is XSA-296 > followup and RFC for-4.13 with no comments for/against.  This has also > stalled with no acks, no concrete suggestion for changes or ways forward. On the 4th I replied "I can see t

Re: [Xen-devel] Status of 4.13

On 21.11.2019 17:03, George Dunlap wrote: > > >> On Nov 21, 2019, at 3:34 PM, Jan Beulich wrote: >> >> On 21.11.2019 16:20, George Dunlap wrote: >>> >>> On Nov 21, 2019, at 8:41 AM, Jan Beulich wrote: On 21.11.2019 08:36, Jürgen Groß wrote: > On 21.11.19 08:30, Steven Haigh w

Re: [Xen-devel] [PATCH for-next v3 9/9] x86: introduce CONFIG_HYPERV and detection code

On 21.11.2019 17:27, Wei Liu wrote: > On Fri, Nov 15, 2019 at 03:07:29PM +0100, Jan Beulich wrote: >> On 21.10.2019 17:57, Wei Liu wrote: >>> --- a/xen/arch/x86/Kconfig >>> +++ b/xen/arch/x86/Kconfig >>> @@ -164,6 +164,15 @@ endchoice >>> config GUEST >>> bool >>> >>> +config HYPERV_GUEST >>

Re: [Xen-devel] [PATCH for-next v3 9/9] x86: introduce CONFIG_HYPERV and detection code

On Thu, Nov 21, 2019 at 05:59:16PM +0100, Jan Beulich wrote: > >> > >> Also how about having *_probe() return the address of *_ops, such > >> that the latter could all become static? > > > > Previously you made a suggestion to make probe return the name of the > > hypervisor. Here you ask for addr

Re: [Xen-devel] [PATCH v1 1/2] x86/cpu: maintain a parked CPU bitmap

On 21.11.2019 12:43, Chao Gao wrote: > On Thu, Nov 21, 2019 at 11:02:10AM +0100, Jan Beulich wrote: >> On 21.11.2019 10:47, Julien Grall wrote: >>> On 20/11/2019 23:05, Chao Gao wrote: --- a/xen/arch/arm/smpboot.c +++ b/xen/arch/arm/smpboot.c @@ -39,6 +39,7 @@ cpumask_t cpu_on

Re: [Xen-devel] Status of 4.13

On Thu, Nov 21, 2019 at 4:16 PM Ian Jackson wrote: > > Wei Liu writes ("Re: Status of 4.13"): > > FWIW I've pushed all the toolstack patches that I'm aware of. > > The only thing outstanding that I am aware of is > [PATCH for-4.13 v1 1/2] libxl: introduce new backend type VINPUT > of which I am a

Re: [Xen-devel] [PATCH v1 2/2] microcode: reject late ucode loading if any core is parked

On 21.11.2019 12:51, Chao Gao wrote: > On Thu, Nov 21, 2019 at 11:21:13AM +0100, Jan Beulich wrote: >> On 21.11.2019 00:05, Chao Gao wrote: >>> If a core with all of its thread being parked, late ucode loading >>> which currently only loads ucode on online threads would lead to >>> differing ucode

Re: [Xen-devel] Status of 4.13

On Wed, Nov 20, 2019 at 10:06 PM Jürgen Groß wrote: > > Where do we stand with Xen 4.13 regarding blockers and related patches? > > 1. OSStest failure regarding nested test: > I'm not quite sure whether the currently debated patch of Andrew is > fixing the problem. If not, do we know what

Re: [Xen-devel] Status of 4.13

On 21/11/2019 17:31, Roman Shaposhnik wrote: > On Wed, Nov 20, 2019 at 10:06 PM Jürgen Groß wrote: >> Where do we stand with Xen 4.13 regarding blockers and related patches? >> >> 1. OSStest failure regarding nested test: >> I'm not quite sure whether the currently debated patch of Andrew is >

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

flight 144232 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/144232/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 144042 test-amd64-amd64-q

[Xen-devel] [PATCH v2 2/3] libxl: rename VKB backend type "linux" to "pv"

From: Oleksandr Grytsov There are two kind of VKB backends: QEMU and user space PV backend. For PV backend "linux" enum is used but this name is confused. Rename "linux" enum to "pv" as it better matches user space PV backend. Signed-off-by: Oleksandr Grytsov --- docs/man/xl.cfg.5.pod.in|

[Xen-devel] [PATCH v2 3/3] libxl: make default path to add/remove all PV devices

From: Oleksandr Grytsov Adding/removing device is handled for specific devices only: VBD, VIF, QDISK. This commit adds default case to handle adding/removing for all PV devices by default, except QDISK device, which requires special handling. If any other device is required a special handling it

[Xen-devel] [PATCH v2 0/3] Remove backend xen store entry on domain destroy

From: Oleksandr Grytsov Changes since v1: * add commit to rename VKB backend type "linux" to "pv"; * add default case to handle adding/removing PV devices in add_device, remove_device functions (libxl_device.c); * add comment about removing num_vifs, num_vbds into commit message. Oleksandr Gr

[Xen-devel] [PATCH v2 1/3] libxl: introduce new backend type VINPUT

From: Oleksandr Grytsov There are two kind of VKBD devices: with QEMU backend and user space PV backend. In current implementation they can't be distinguished as both use VKBD backend type. As result, user space PV KBD backend is started and stopped as QEMU backend. This commit adds new device ki

[Xen-devel] [PATCH v4 0/8] Port Xen to Hyper-V

Please see individual patches for changes. Cc: Jan Beulich Cc: Andrew Cooper Cc: Wei Liu

Re: [Xen-devel] [PATCH] arch: arm: vgic-v3: fix GICD_ISACTIVER range

On Tue, 19 Nov 2019, Julien Grall wrote: > Hi Andre, > > On 12/11/2019 12:46, Andre Przywara wrote: > > On Mon, 11 Nov 2019 11:01:07 -0800 (PST) > > Stefano Stabellini wrote: > > > On Sat, 9 Nov 2019, Julien Grall wrote: > > > > On Sat, 9 Nov 2019, 04:27 Stefano Stabellini, > > > > wrote: > > >

[Xen-devel] [PATCH v4 3/8] x86: drop hypervisor_cpuid_base

The only user is Xen specific code in PV shim. We can therefore export the variable directly. Move __read_mostly to its standard place while at it. Signed-off-by: Wei Liu Reviewed-by: Roger Pau Monné Acked-by: Jan Beulich --- xen/arch/x86/guest/xen/xen.c| 7 +-- xen/arch/x86/pv/shim.c

[Xen-devel] [PATCH v4 1/8] x86: introduce CONFIG_GUEST and move code

Xen is able to run as a guest on Xen. We plan to make it able to run on Hyper-V as well. Introduce CONFIG_GUEST which is set to true if either running on Xen or Hyper-V is desired. Restructure code hierarchy for new code to come. No functional change intended. Signed-off-by: Wei Liu Reviewed-by

[Xen-devel] [PATCH v4 8/8] x86: introduce CONFIG_HYPERV and detection code

We use the same code structure as we did for Xen. As starters, detect Hyper-V in probe routine. More complex functionalities will be added later. Take the chance to fix XEN_GUEST in Kconfig. Signed-off-by: Wei Liu --- Changes in V4: 1. Add comment regarding order of probe functions. 2. Adapt to

[Xen-devel] [PATCH v4 2/8] x86: add missing headers in hypercall.h

Include asm_defns.h because ASM_CALL_CONSTRAINT is defined there. Include xen/lib.h because we need ASSERT_UNREACHABLE. No functional change. Signed-off-by: Wei Liu Reviewed-by: Roger Pau Monné Acked-by: Jan Beulich --- xen/include/asm-x86/guest/hypercall.h | 4 1 file changed, 4 insert

[Xen-devel] [PATCH v4 5/8] x86: rename hypervisor_{alloc, free}_unused_page

They are used in Xen code only. No functional change. Signed-off-by: Wei Liu --- Changes in v4: 1. Use xg_ prefix instead. 2. Drop Roger's review tag. --- xen/arch/x86/guest/xen/xen.c| 6 +++--- xen/arch/x86/pv/shim.c | 4 ++-- xen/include/asm-x86/guest/xen.h | 4 ++-- 3 files chan

[Xen-devel] [PATCH v4 6/8] x86: switch xen guest implementation to use hypervisor framework

Signed-off-by: Wei Liu --- Changes in v4: 1. xen_probe returns address of ops directly. 2. Add __init to hypervisor_setup. 3. Drop Paul's review tag. --- xen/arch/x86/guest/hypervisor.c | 32 - xen/arch/x86/guest/xen/pvh-boot.c | 2 +- xen/arch/x86/guest/xen/xen.c | 47

[Xen-devel] [PATCH v4 4/8] x86: introduce hypervisor framework

We will soon implement Hyper-V support for Xen. Add a framework for that. This requires moving some of the hypervisor_* functions from xen.h to hypervisor.h. Signed-off-by: Wei Liu --- Changes in v4: 1. Add ASSERT_UNREACHABLE to stubs. 2. Move __read_mostly. 3. Return hops directly. 4. Drop Paul

[Xen-devel] [PATCH v4 7/8] x86: be more verbose when running on a hypervisor

Also replace xen_guest with running_on_hypervisor boolean. Signed-off-by: Wei Liu --- Changes in v4: 1. Access ->name directly. 2. Drop Roger's review tag. --- xen/arch/x86/setup.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setu

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

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

Re: [Xen-devel] [PATCH] arch: arm: vgic-v3: fix GICD_ISACTIVER range

Hi Stefano, On 21/11/2019 18:50, Stefano Stabellini wrote: On Tue, 19 Nov 2019, Julien Grall wrote: Hi Andre, On 12/11/2019 12:46, Andre Przywara wrote: On Mon, 11 Nov 2019 11:01:07 -0800 (PST) Stefano Stabellini wrote: On Sat, 9 Nov 2019, Julien Grall wrote: On Sat, 9 Nov 2019, 04:27 Stef

Re: [Xen-devel] Status of 4.13

On Thu, Nov 21, 2019 at 9:38 AM Andrew Cooper wrote: > > On 21/11/2019 17:31, Roman Shaposhnik wrote: > > On Wed, Nov 20, 2019 at 10:06 PM Jürgen Groß wrote: > >> Where do we stand with Xen 4.13 regarding blockers and related patches? > >> > >> 1. OSStest failure regarding nested test: > >> I

[Xen-devel] [xen-4.11-testing test] 144234: regressions - FAIL

flight 144234 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/144234/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 144025 Tests

Re: [Xen-devel] Status of 4.13

On Thu, Nov 21, 2019 at 11:39:14AM -0800, Roman Shaposhnik wrote: > On Thu, Nov 21, 2019 at 9:38 AM Andrew Cooper > wrote: > > > > On 21/11/2019 17:31, Roman Shaposhnik wrote: > > > On Wed, Nov 20, 2019 at 10:06 PM Jürgen Groß wrote: > > >> Where do we stand with Xen 4.13 regarding blockers and

[Xen-devel] [PATCH for-4.13 0/2] x86/hvm: Multiple corrections to task switch handling

These patches want backporting due to the severity of patch 2. They should therefore be considered for 4.13 at this point. Andrew Cooper (2): x86/vtx: Fix fault semantics for early task switch failures x86/svm: Write the correct %eip into the outgoing task xen/arch/x86/hvm/hvm.c

[Xen-devel] [PATCH 2/2] x86/svm: Write the correct %eip into the outgoing task

The TASK_SWITCH vmexit has fault semantics, and doesn't provide any NRIPs assistance with instruction length. As a result, any instruction-induced task switch has the outgoing task's %eip pointing at the instruction switch caused the switch, rather than after it. This causes explicit use of task

[Xen-devel] [PATCH 1/2] x86/vtx: Fix fault semantics for early task switch failures

The VT-x task switch handler adds inst_len to rip before calling hvm_task_switch(). This causes early faults to be delivered to the guest with trap semantics, and break restartibility. Instead, pass the instruction length into hvm_task_switch() and write it into the outgoing tss only, leaving rip

Re: [Xen-devel] [PATCH] arch: arm: vgic-v3: fix GICD_ISACTIVER range

On Thu, 21 Nov 2019, Julien Grall wrote: > > > As I said in a different sub-thread, I would reluctanly be ok to see > > > returning > > > 0 as long as we have add a warning for *every* access. Long-term, the > > > current > > > vGIC should really get killed. After speaking with Julien and reading

[Xen-devel] [xen-4.12-testing test] 144235: regressions - FAIL

flight 144235 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/144235/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 144035 Tests

Re: [Xen-devel] [PATCH 1/3] arm/arm64/xen: use C inlines for privcmd_call

On Thu, Nov 21, 2019 at 01:48:03PM -0500, Pavel Tatashin wrote: > privcmd_call requires to enable access to userspace for the > duration of the hypercall. > > Currently, this is done via assembly macros. Change it to C > inlines instead. > > Signed-off-by: Pavel Tatashin > --- > arch/arm/includ

Re: [Xen-devel] [PATCH 1/3] arm/arm64/xen: use C inlines for privcmd_call

On Thu, Nov 21, 2019 at 07:30:41PM -0500, Pavel Tatashin wrote: > > > +#ifdef CONFIG_CPU_SW_DOMAIN_PAN > > > +static __always_inline void uaccess_enable(void) > > > +{ > > > + unsigned long val = DACR_UACCESS_ENABLE; > > > + > > > + asm volatile("mcr p15, 0, %0, c3, c0, 0" : : "r" (val)); >

Re: [Xen-devel] [PATCH 1/3] arm/arm64/xen: use C inlines for privcmd_call

On Fri, Nov 22, 2019 at 12:34:03AM +, Russell King - ARM Linux admin wrote: > On Thu, Nov 21, 2019 at 07:30:41PM -0500, Pavel Tatashin wrote: > > > > +#ifdef CONFIG_CPU_SW_DOMAIN_PAN > > > > +static __always_inline void uaccess_enable(void) > > > > +{ > > > > + unsigned long val = DACR_UACC

Re: [Xen-devel] [PATCH 1/3] arm/arm64/xen: use C inlines for privcmd_call

On Thu, Nov 21, 2019 at 07:39:22PM -0500, Pavel Tatashin wrote: > > > That may be, but be very careful that you only use them in ARMv7-only > > > code. Using them elsewhere is unsafe as the domain register is used > > > for other purposes, and merely blatting over it (as your > > > uaccess_enable

Re: [Xen-devel] [PATCH 3/3] arm64: remove the rest of asm-uaccess.h

On Thu, Nov 21, 2019 at 10:50 AM Pavel Tatashin wrote: > > The __uaccess_ttbr0_disable and __uaccess_ttbr0_enable, > are the last two macros defined in asm-uaccess.h. > > Replace them with C wrappers and call C functions from > kernel_entry and kernel_exit. > > Signed-off-by: Pavel Tatashin > ---

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

flight 144236 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/144236/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 144229 test-amd64-amd64-xl-qemuu-win7-amd6

Re: [Xen-devel] Status of 4.13

On Nov 21, 2019, at 17:11, Marek Marczykowski-Górecki wrote: > > On Thu, Nov 21, 2019 at 11:39:14AM -0800, Roman Shaposhnik wrote: >>> On Thu, Nov 21, 2019 at 9:38 AM Andrew Cooper >>> wrote: >>> On 21/11/2019 17:31, Roman Shaposhnik wrote: >> On Wed, Nov 20, 2019 at 10:06 PM Jürgen Groß

[Xen-devel] [PATCH 2/3] arm64: remove uaccess_ttbr0 asm macros from cache functions

Replace the uaccess_ttbr0_disable/uaccess_ttbr0_enable via inline variants, and remove asm macros. Signed-off-by: Pavel Tatashin --- arch/arm64/include/asm/asm-uaccess.h | 22 arch/arm64/include/asm/cacheflush.h | 38 +--- arch/arm64/mm/cache.S

  1   2   >