Re: [Xen-devel] [PATCH] x86/cpu: Support a new cpu vendor, which is Shanghai

Hi Jan， Yes, I mean with another patch. And Thank you again. -Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Wednesday, April 18, 2018 6:52 PM To: Fiona Li(BJ-RD) Cc: xen-devel Subject: RE: RE: [PATCH] x86/cpu:

[Xen-devel] [PATCH 5/6] arm: add a small kconfig for qemu-system-aarch64

Disable erratas because they don't apply to QEMU's software emulated CPUs. Arbitrarily choose a limit of 4 CPUs. Select the credit and NULL schedulers only. Signed-off-by: Stefano Stabellini --- xen/arch/arm/configs/qemu.config | 81

[Xen-devel] [PATCH 0/6] arm: more kconfig configurability and small default configs

Hi all, This patch series is the first step toward building a small certifiable Xen hypervisor for ARM boards. First, the series makes a few changes to allow disabling more kconfig options: most of them already exist but cannot be disabled. Then, it introduces a reference kconfig for Renesas

Re: [Xen-devel] [PATCHv2] x86/xen: Remove use of VLAs

On 04/18/2018 01:08 PM, Laura Abbott wrote: > There's an ongoing effort to remove VLAs[1] from the kernel to eventually > turn on -Wvla. It turns out, the few VLAs in use in Xen produce only a > single entry array that is always bounded by GDT_SIZE. Clean up the code to > get rid of the VLA and

[Xen-devel] [PATCH 4/6] arm: add a small kconfig for Renesas RCar H3

This is a reference tiny kconfig for Renesas RCar. In terms of schedulers, it selects credit and NULL only. It enables all the ARM64 errata. Signed-off-by: Stefano Stabellini CC: artem_myga...@epam.com CC: volodymyr_babc...@epam.com --- This patch is untested on

[Xen-devel] [PATCH 6/6] xen: add cloc target

Add a Xen build target to count the lines of code of the source files built. Uses `cloc' to do the job. Generate the list of source files from the %.o targets, append output to "sourcelist". Remove sourcelist on clean, and also at the beginning of the build target to avoid appending to

[Xen-devel] [PATCH 1/6] arm: make it possible to disable more kconfig options

Make it possible to disable the following existing kconfig options: HAS_GICV3 HAS_ARM_HDLCD HAS_MEM_ACCESS Today they are silent option. This patch adds one line descriptions and make them de/selectable. Also, do not select VIDEO: make HAS_ARM_HDLCD select VIDEO instead. In fact, VIDEO is

[Xen-devel] [PATCH 2/6] arm: make it possible to enable/disable UART drivers

All the UART drivers are silent options. Add one line descriptions so that can be de/selected via menuconfig. Signed-off-by: Stefano Stabellini --- xen/drivers/char/Kconfig | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git

[Xen-devel] [PATCH 3/6] arm: make it possible to disable the SMMU driver

Introduce a Kconfig option for the ARM SMMUv2 driver. Signed-off-by: Stefano Stabellini CC: jbeul...@suse.com --- xen/drivers/passthrough/Kconfig | 2 ++ xen/drivers/passthrough/arm/Kconfig | 7 +++ xen/drivers/passthrough/arm/Makefile | 2 +- 3 files changed,

[Xen-devel] [PATCH for-4.11] x86/spec_ctrl: Updates to retpoline-safety decision making

All of this is as recommended by the Intel whitepaper: https://software.intel.com/sites/default/files/managed/1d/46/Retpoline-A-Branch-Target-Injection-Mitigation.pdf The RSB-alternative bit in MSR_ARCH_CAPABILITIES may be set by a hypervisor to indicate that the virtual machine may migrate to a

Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction

On Sat, 14 Apr 2018, Paul Durrant wrote: > > -Original Message- > > From: Roger Pau Monne > > Sent: 13 April 2018 20:53 > > To: Lars Kurth > > Cc: xen-devel ; Daniel Smith > > ; Alexey G

[Xen-devel] [PATCHv2] x86/xen: Remove use of VLAs

There's an ongoing effort to remove VLAs[1] from the kernel to eventually turn on -Wvla. It turns out, the few VLAs in use in Xen produce only a single entry array that is always bounded by GDT_SIZE. Clean up the code to get rid of the VLA and the loop. [1] https://lkml.org/lkml/2018/3/7/621

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: > On 04/17/2018 11:57 PM, Dongwon Kim wrote: > >On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: > >>On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: > >>>Yeah, I definitely agree on the idea of

Re: [Xen-devel] [PATCH for-4.11] x86: Use spec_ctrl_{enter, exit}_idle() in the S3/S5 path

On 18/04/18 17:14, Jan Beulich wrote: On 18.04.18 at 18:02, wrote: >> On 18/04/18 16:43, Jan Beulich wrote: >> On 18.04.18 at 12:43, wrote: This avoids opencoding the functionality (and missing one bit of it), and and

Re: [Xen-devel] [PATCH for-4.11] x86: Use spec_ctrl_{enter, exit}_idle() in the S3/S5 path

>>> On 18.04.18 at 18:02, wrote: > On 18/04/18 16:43, Jan Beulich wrote: > On 18.04.18 at 12:43, wrote: >>> This avoids opencoding the functionality (and missing one bit of it), and >>> and >>> some comments explaining what is going on.

Re: [Xen-devel] [PATCH v8 1/9] x86/xpti: avoid copying L4 page table contents when possible

>>> On 18.04.18 at 10:30, wrote: > @@ -160,5 +161,20 @@ unsigned int flush_area_local(const void *va, unsigned > int flags) > > local_irq_restore(irqfl); > > +if ( flags & FLUSH_ROOT_PGTBL ) > +get_cpu_info()->root_pgt_changed = true; > + > return

Re: [Xen-devel] [PATCH v8 3/9] xen/x86: support per-domain flag for xpti

>>> On 18.04.18 at 17:54, wrote: > On 18/04/18 17:45, Jan Beulich wrote: > On 18.04.18 at 17:33, wrote: >>> On 18/04/18 17:29, Jan Beulich wrote: >>> On 18.04.18 at 10:30, wrote: > --- a/xen/arch/x86/mm/shadow/multi.c > +++

Re: [Xen-devel] [PATCH for-4.11] x86: Use spec_ctrl_{enter, exit}_idle() in the S3/S5 path

On 18/04/18 16:43, Jan Beulich wrote: On 18.04.18 at 12:43, wrote: >> This avoids opencoding the functionality (and missing one bit of it), and and >> some comments explaining what is going on. > Missing which bit of it? The MSR writes aren't strictly necessary

Re: [Xen-devel] [PATCH v5] x86/setup: properly update PTEs if src/dst overlaps when relocating Xen image

>>> On 18.04.18 at 12:26, wrote: > @@ -1019,6 +1020,12 @@ void __init noreturn __start_xen(unsigned long mbi_p) > bootsym(trampoline_xen_phys_start) = e; > > /* > + * All PTEs with PFNs above pte_update_limit > + * were

Re: [Xen-devel] [PATCH v8 3/9] xen/x86: support per-domain flag for xpti

>>> On 18.04.18 at 17:33, wrote: > On 18/04/18 17:29, Jan Beulich wrote: > On 18.04.18 at 10:30, wrote: >>> --- a/xen/arch/x86/mm/shadow/multi.c >>> +++ b/xen/arch/x86/mm/shadow/multi.c >>> @@ -967,7 +967,7 @@ static int shadow_set_l4e(struct domain *d, >>>

Re: [Xen-devel] [PATCH for-4.11] x86: Use spec_ctrl_{enter, exit}_idle() in the S3/S5 path

>>> On 18.04.18 at 12:43, wrote: > This avoids opencoding the functionality (and missing one bit of it), and and > some comments explaining what is going on. Missing which bit of it? The MSR writes aren't strictly necessary afaict, and functionally clearing

Re: [Xen-devel] [PATCH v8 9/9] xen/x86: use PCID feature

On 18/04/18 17:32, Jan Beulich wrote: On 18.04.18 at 11:37, wrote: >> On 18/04/18 11:13, Jan Beulich wrote: >> On 18.04.18 at 10:30, wrote: Avoid flushing the complete TLB when switching %cr3 for mitigation of Meltdown by using the PCID

Re: [Xen-devel] [PATCH v8 9/9] xen/x86: use PCID feature

>>> On 18.04.18 at 11:37, wrote: > On 18/04/18 11:13, Jan Beulich wrote: > On 18.04.18 at 10:30, wrote: >>> Avoid flushing the complete TLB when switching %cr3 for mitigation of >>> Meltdown by using the PCID feature if available. >>> >>> We are using 4 PCID

Re: [Xen-devel] [PATCH v2 0/5] ALSA: xen-front: Add Xen para-virtualized frontend driver

On 04/16/2018 09:24 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Please note: this patch series depends on [3]. The dependency is now merged into Xen kernel tree [4] for-linus-4.17 This patch series adds support for Xen [1]

[Xen-devel] [PATCH] Input: xen-kbdfront - allow better run-time configuration

From: Oleksandr Andrushchenko It is now only possible to control if multi-touch virtual device is created or not (via the corresponding XenStore entries), but keyboard and pointer devices are always created. In some cases this is not desirable. For example, if

[Xen-devel] [PATCH V2] x86/p2m: fixed p2m_change_type_range() start / end check

p2m_change_type_range() handles end > max_mapped_pfn, but not start > max_mapped_pfn. Check the latter just after grabbing the lock and bail if true. Signed-off-by: Razvan Cojocaru Suggested-by: George Dunlap --- Changes since V1: - Added

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 04/18/2018 01:55 PM, Roger Pau Monné wrote: On Wed, Apr 18, 2018 at 01:39:35PM +0300, Oleksandr Andrushchenko wrote: On 04/18/2018 01:18 PM, Paul Durrant wrote: -Original Message- From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of Roger Pau Monné Sent: 18

Re: [Xen-devel] [RFC Patch v4 7/8] x86/hvm: bump the number of pages of shadow memory

>>> On 18.04.18 at 13:39, wrote: > On Wed, Apr 18, 2018 at 02:53:03AM -0600, Jan Beulich wrote: > On 06.12.17 at 08:50, wrote: >>> Each vcpu of hvm guest consumes at least one shadow page. Currently, only > 256 >>> (for hap case) pages are

Re: [Xen-devel] [RFC Patch v4 7/8] x86/hvm: bump the number of pages of shadow memory

On 18/04/18 12:39, Chao Gao wrote: > On Wed, Apr 18, 2018 at 02:53:03AM -0600, Jan Beulich wrote: > On 06.12.17 at 08:50, wrote: >>> Each vcpu of hvm guest consumes at least one shadow page. Currently, only >>> 256 >>> (for hap case) pages are pre-allocated as shadow

Re: [Xen-devel] [RFC Patch v4 7/8] x86/hvm: bump the number of pages of shadow memory

On Wed, Apr 18, 2018 at 02:53:03AM -0600, Jan Beulich wrote: On 06.12.17 at 08:50, wrote: >> Each vcpu of hvm guest consumes at least one shadow page. Currently, only 256 >> (for hap case) pages are pre-allocated as shadow memory at beginning. It >> would >> run out if

Re: [Xen-devel] [PATCH] mktarball: For qemu upstream, use their scripts/archive-source.sh

On Tue, Apr 17, 2018 at 06:04:37PM +0100, Ian Jackson wrote: > diff --git a/tools/misc/mktarball b/tools/misc/mktarball > index 73282b5..42d5430 100755 > --- a/tools/misc/mktarball > +++ b/tools/misc/mktarball > @@ -29,7 +29,21 @@ mkdir -p $tdir > > git_archive_into $xen_root $tdir/xen-$desc >

Re: [Xen-devel] [RFC Patch v4 4/8] hvmloader: boot cpu through broadcast

On Wed, Apr 18, 2018 at 02:38:48AM -0600, Jan Beulich wrote: On 06.12.17 at 08:50, wrote: >> Intel SDM Extended XAPIC (X2APIC) -> "Initialization by System Software" >> has the following description: >> >> "The ACPI interfaces for the x2APIC are described in Section 5.2,

Re: [Xen-devel] [PATCH] x86/p2m: fixed p2m_change_type_range() start / end check

On 04/18/2018 11:53 AM, Jan Beulich wrote: On 18.04.18 at 12:23, wrote: >> That is, sensible input looks like: >> * start < end >> * For hostp2ms: >> - start <= max_mapped_pfn >> - either end <= max_mapped_pfn, or end == ~0UL >> (But for altp2ms, start or end >

Re: [Xen-devel] [PATCH 6/7] xen/arm: Setup virtual paging for secondary CPUs in non-boot scenario

On 18/04/18 11:45, Mirela Simonovic wrote: On Tue, Apr 17, 2018 at 4:11 PM, Julien Grall wrote: On 17/04/18 13:54, Mirela Simonovic wrote: Hi Julien, Hi, On Wed, Apr 11, 2018 at 5:11 PM, Julien Grall wrote: Hi, On 11/04/18 14:19,

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On Wed, Apr 18, 2018 at 01:39:35PM +0300, Oleksandr Andrushchenko wrote: > On 04/18/2018 01:18 PM, Paul Durrant wrote: > > > -Original Message- > > > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > > > Of Roger Pau Monné > > > Sent: 18 April 2018 11:11 > > > To:

Re: [Xen-devel] [PATCH] x86/p2m: fixed p2m_change_type_range() start / end check

>>> On 18.04.18 at 12:23, wrote: > That is, sensible input looks like: > * start < end > * For hostp2ms: > - start <= max_mapped_pfn > - either end <= max_mapped_pfn, or end == ~0UL > (But for altp2ms, start or end > max_mapped_pfn is fine.) So I guess that's part of

Re: [Xen-devel] [PATCH] x86/cpu: Support a new cpu vendor, which is Shanghai

>>> On 18.04.18 at 12:25, wrote: > [FionaLi] : I am sorry. I understood wrongly. The C000 range are > extensions, which provide some additional feature different from Intel. As > you suggested, we will enable those features in guest OSes and remove these > code from

Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view

On 04/18/2018 01:45 PM, George Dunlap wrote: > On 04/18/2018 09:20 AM, Razvan Cojocaru wrote: >> On 04/17/2018 04:53 PM, George Dunlap wrote: >>> On 04/17/2018 11:50 AM, Razvan Cojocaru wrote: void p2m_init_altp2m_ept(struct domain *d, unsigned int i) { struct p2m_domain *p2m

Re: [Xen-devel] [PATCH 6/7] xen/arm: Setup virtual paging for secondary CPUs in non-boot scenario

On Tue, Apr 17, 2018 at 4:11 PM, Julien Grall wrote: > > > On 17/04/18 13:54, Mirela Simonovic wrote: >> >> Hi Julien, > > > Hi, > >> >> On Wed, Apr 11, 2018 at 5:11 PM, Julien Grall >> wrote: >>> >>> Hi, >>> >>> On 11/04/18 14:19, Mirela Simonovic

Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view

On 04/18/2018 09:20 AM, Razvan Cojocaru wrote: > On 04/17/2018 04:53 PM, George Dunlap wrote: >> On 04/17/2018 11:50 AM, Razvan Cojocaru wrote: >>> void p2m_init_altp2m_ept(struct domain *d, unsigned int i) >>> { >>> struct p2m_domain *p2m = d->arch.altp2m_p2m[i]; >>> +struct p2m_domain

[Xen-devel] [PATCH for-4.11] x86: Use spec_ctrl_{enter, exit}_idle() in the S3/S5 path

This avoids opencoding the functionality (and missing one bit of it), and and some comments explaining what is going on. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Juergen Gross This is effectively a bugfix of c/s

Re: [Xen-devel] [PATCH] x86/cpu: Support a new cpu vendor, which is Shanghai

Jan Thanks for your reply. Answer the following. Best wish! FionaLi -Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Tuesday, April 10, 2018 2:35 PM To: lifang...@126.com; Fiona Li(BJ-RD) Cc: xen-devel@lists.xenproject.org Subject: Re: RE:

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 04/18/2018 01:18 PM, Paul Durrant wrote: -Original Message- From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of Roger Pau Monné Sent: 18 April 2018 11:11 To: Oleksandr Andrushchenko Cc: jgr...@suse.com; Artem Mygaiev

Re: [Xen-devel] [PATCH 6/7] xen/arm: Setup virtual paging for secondary CPUs in non-boot scenario

Hi Julien, On Wed, Apr 18, 2018 at 11:48 AM, Julien Grall wrote: > > > On 17/04/18 16:22, Mirela Simonovic wrote: >> >> Hi Julien, >> >> On Tue, Apr 17, 2018 at 4:11 PM, Julien Grall >> wrote: >>> >>> >>> >>> On 17/04/18 13:54, Mirela Simonovic wrote:

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 04/18/2018 01:23 PM, Paul Durrant wrote: -Original Message- From: Oleksandr Andrushchenko [mailto:andr2...@gmail.com] Sent: 18 April 2018 11:21 To: Paul Durrant ; Roger Pau Monne Cc: jgr...@suse.com; Artem Mygaiev

[Xen-devel] [PATCH v5] x86/setup: properly update PTEs if src/dst overlaps when relocating Xen image

Commit 0d31d16 (x86/setup: do not relocate Xen over current Xen image placement) disallowed src/dst images overlaps when relocating Xen image. Though it deliberately allowed destination region between __image_base__ and (__image_base__ + XEN_IMG_OFFSET) overlaps with the end of source image. And

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

> -Original Message- > From: Oleksandr Andrushchenko [mailto:andr2...@gmail.com] > Sent: 18 April 2018 11:21 > To: Paul Durrant ; Roger Pau Monne > > Cc: jgr...@suse.com; Artem Mygaiev ; > Dongwon Kim

Re: [Xen-devel] [PATCH] x86/p2m: fixed p2m_change_type_range() start / end check

On 04/18/2018 08:38 AM, Jan Beulich wrote: On 17.04.18 at 19:16, wrote: >> --- a/xen/arch/x86/mm/p2m.c >> +++ b/xen/arch/x86/mm/p2m.c >> @@ -976,6 +976,13 @@ void p2m_change_type_range(struct domain *d, >> ASSERT(p2m_is_changeable(ot) &&

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 04/18/2018 01:18 PM, Paul Durrant wrote: -Original Message- From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of Roger Pau Monné Sent: 18 April 2018 11:11 To: Oleksandr Andrushchenko Cc: jgr...@suse.com; Artem Mygaiev

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Roger Pau Monné > Sent: 18 April 2018 11:11 > To: Oleksandr Andrushchenko > Cc: jgr...@suse.com; Artem Mygaiev ; > Dongwon Kim

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko wrote: > On 04/18/2018 10:35 AM, Roger Pau Monné wrote: > > On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: > > > On 04/17/2018 11:57 PM, Dongwon Kim wrote: > > > > On Tue, Apr 17, 2018 at 09:59:28AM +0200,

Re: [Xen-devel] [PATCH v8 3/9] xen/x86: support per-domain flag for xpti

On 18/04/18 11:42, Sergey Dyasli wrote: > Hi Juergen, > > 2 small requests from me below. > > On Wed, 2018-04-18 at 10:30 +0200, Juergen Gross wrote: >> Instead of switching XPTI globally on or off add a per-domain flag for >> that purpose. This allows to modify the xpti boot parameter to

Re: [Xen-devel] [PATCH v8 3/9] xen/x86: support per-domain flag for xpti

On 18/04/18 11:49, Jan Beulich wrote: On 18.04.18 at 11:42, wrote: >> On Wed, 2018-04-18 at 10:30 +0200, Juergen Gross wrote: >> @@ -119,8 +122,9 @@ static void __init print_details(enum ind_thunk thunk) >> boot_cpu_has(X86_FEATURE_RSB_NATIVE) ? "

Re: [Xen-devel] [PATCH 6/7] xen/arm: Setup virtual paging for secondary CPUs in non-boot scenario

On 17/04/18 16:22, Mirela Simonovic wrote: Hi Julien, On Tue, Apr 17, 2018 at 4:11 PM, Julien Grall wrote: On 17/04/18 13:54, Mirela Simonovic wrote: Hi Julien, Hi, On Wed, Apr 11, 2018 at 5:11 PM, Julien Grall wrote: Hi, On 11/04/18

Re: [Xen-devel] [PATCH v8 3/9] xen/x86: support per-domain flag for xpti

>>> On 18.04.18 at 11:42, wrote: > On Wed, 2018-04-18 at 10:30 +0200, Juergen Gross wrote: > @@ -119,8 +122,9 @@ static void __init print_details(enum ind_thunk thunk) > boot_cpu_has(X86_FEATURE_RSB_NATIVE) ? " RSB_NATIVE" : "", >

Re: [Xen-devel] [PATCH v8 3/9] xen/x86: support per-domain flag for xpti

Hi Juergen, 2 small requests from me below. On Wed, 2018-04-18 at 10:30 +0200, Juergen Gross wrote: > Instead of switching XPTI globally on or off add a per-domain flag for > that purpose. This allows to modify the xpti boot parameter to support > running dom0 without Meltdown mitigations. Using

Re: [Xen-devel] [PATCH v8 9/9] xen/x86: use PCID feature

On 18/04/18 11:13, Jan Beulich wrote: On 18.04.18 at 10:30, wrote: >> Avoid flushing the complete TLB when switching %cr3 for mitigation of >> Meltdown by using the PCID feature if available. >> >> We are using 4 PCID values for a 64 bit pv domain subject to XPTI and >> 2

[Xen-devel] [PATCH v2] x86/hpet: Fix possible ASSERT(cpu < nr_cpu_ids)

From: David Wang For the ch->cpumask be cleared by other cpu, cpumask_first() called by hpet_detach_channel() return nr_cpu_ids. That lead an assertion in set_channel_irq_affinity() when cpumask_of() check cpu. Fix this by using a local variable. Signed-off-by: David Wang

[Xen-devel] Announcing the Xen Project 4.11 RC and Test Day Schedules

Dear community members, on Tuesday, we created Xen 4.1q RC1 and will release a new release candidate every FRIDAY, until we declare a release candidate as the final candidate and cut the Xen 4.11 release. We will also hold a Test Day every TUESDAY for the release candidate that was released the

Re: [Xen-devel] [PATCH v8 9/9] xen/x86: use PCID feature

>>> On 18.04.18 at 10:30, wrote: > Avoid flushing the complete TLB when switching %cr3 for mitigation of > Meltdown by using the PCID feature if available. > > We are using 4 PCID values for a 64 bit pv domain subject to XPTI and > 2 values for the non-XPTI case: > > - guest

Re: [Xen-devel] [RFC Patch v4 7/8] x86/hvm: bump the number of pages of shadow memory

>>> On 06.12.17 at 08:50, wrote: > Each vcpu of hvm guest consumes at least one shadow page. Currently, only 256 > (for hap case) pages are pre-allocated as shadow memory at beginning. It would > run out if guest has more than 256 vcpus and guest creation fails. Bump the >

Re: [Xen-devel] [RFC Patch v4 6/8] hvmload: Add x2apic entry support in the MADT and SRAT build

>>> On 06.12.17 at 08:50, wrote: > --- a/tools/libacpi/build.c > +++ b/tools/libacpi/build.c > @@ -30,6 +30,11 @@ > > #define align16(sz)(((sz) + 15) & ~15) > #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d)) > +#define min(X, Y) ({

Re: [Xen-devel] [RFC Patch v4 4/8] hvmloader: boot cpu through broadcast

>>> On 06.12.17 at 08:50, wrote: > Intel SDM Extended XAPIC (X2APIC) -> "Initialization by System Software" > has the following description: > > "The ACPI interfaces for the x2APIC are described in Section 5.2, “ACPI System > Description Tables,” of the Advanced Configuration

[Xen-devel] [PATCH v8 2/9] xen/x86: add a function for modifying cr3

Instead of having multiple places with more or less identical asm statements just have one function doing a write to cr3. As this function should be named write_cr3() rename the current write_cr3() function to switch_cr3(). Suggested-by: Andrew Copper Signed-off-by:

[Xen-devel] [PATCH v8 6/9] xen/x86: use flag byte for decision whether xen_cr3 is valid

Today cpu_info->xen_cr3 is either 0 to indicate %cr3 doesn't need to be switched on entry to Xen, or negative for keeping the value while indicating not to restore %cr3, or positive in case %cr3 is to be restored. Switch to use a flag byte instead of a negative xen_cr3 value in order to allow

[Xen-devel] [PATCH v8 3/9] xen/x86: support per-domain flag for xpti

Instead of switching XPTI globally on or off add a per-domain flag for that purpose. This allows to modify the xpti boot parameter to support running dom0 without Meltdown mitigations. Using "xpti=nodom0" as boot parameter will achieve that. Move the xpti boot parameter handling to

[Xen-devel] [PATCH v8 9/9] xen/x86: use PCID feature

Avoid flushing the complete TLB when switching %cr3 for mitigation of Meltdown by using the PCID feature if available. We are using 4 PCID values for a 64 bit pv domain subject to XPTI and 2 values for the non-XPTI case: - guest active and in kernel mode - guest active and in user mode -

[Xen-devel] [PATCH v8 0/9] xen/x86: various XPTI speedups

This patch series aims at reducing the overhead of the XPTI Meltdown mitigation. Patch 1 had been posted before, the main changes in this patch are due to addressing Jan's comments on my first version. The main objective of that patch is to avoid copying the L4 page table each time the guest is

[Xen-devel] [PATCH v8 4/9] xen/x86: use invpcid for flushing the TLB

If possible use the INVPCID instruction for flushing the TLB instead of toggling cr4.pge for that purpose. While at it remove the dependency on cr4.pge being required for mtrr loading, as this will be required later anyway. Add a command line option "invpcid" for controlling the use of INVPCID

[Xen-devel] [PATCH v8 7/9] xen/x86: convert pv_guest_cr4_to_real_cr4() to a function

pv_guest_cr4_to_real_cr4() is becoming more and more complex. Convert it from a macro to an ordinary function. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich --- V6: - new patch, split off from (old) patch 7 (Andrew Cooper) --- xen/arch/x86/mm.c

[Xen-devel] [PATCH v8 8/9] xen/x86: add some cr3 helpers

Add some helper macros to access the address and pcid parts of cr3. Use those helpers where appropriate. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich --- V6: - new patch (Andrew Cooper) --- xen/arch/x86/debug.c| 2 +-

[Xen-devel] [PATCH v8 5/9] xen/x86: disable global pages for domains with XPTI active

Instead of flushing the TLB from global pages when switching address spaces with XPTI being active just disable global pages via %cr4 completely when a domain subject to XPTI is active. This avoids the need for extra TLB flushes as loading %cr3 will remove all TLB entries. In order to avoid

[Xen-devel] [PATCH v8 1/9] x86/xpti: avoid copying L4 page table contents when possible

For mitigation of Meltdown the current L4 page table is copied to the cpu local root page table each time a 64 bit pv guest is entered. Copying can be avoided in cases where the guest L4 page table hasn't been modified while running the hypervisor, e.g. when handling interrupts or any hypercall

Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view

On 04/17/2018 04:53 PM, George Dunlap wrote: > On 04/17/2018 11:50 AM, Razvan Cojocaru wrote: >> void p2m_init_altp2m_ept(struct domain *d, unsigned int i) >> { >> struct p2m_domain *p2m = d->arch.altp2m_p2m[i]; >> +struct p2m_domain *hostp2m = p2m_get_hostp2m(d); >> struct

Re: [Xen-devel] [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 pages

>>> On 06.12.17 at 08:50, wrote: > One 4K-byte page at most contains 128 'ioreq_t'. In order to remove the vcpu > number constraint imposed by one IOREQ page, bump the number of IOREQ page to > 4 pages. With this patch, multiple pages can be used as IOREQ page. In case I

[Xen-devel] [distros-debian-squeeze test] 74632: tolerable FAIL

flight 74632 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74632/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like 74577

Re: [Xen-devel] [PATCH v7 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

I wonder why I am starting to get CCed on Xen patches all of a sudden. I happened to run into Jürgen at a conference only last weekend, but I still don't know anything whatsoever about Xen or how it works. If get_maintainer.pl has started to return my name on this stuff I really want to know why

Re: [Xen-devel] Fwd: [tip:x86/urgent] x86, sched: Allow topologies where NUMA nodes share an LLC

On 4/17/18 6:02 PM, Dario Faggioli wrote: On Tue, 2018-04-17 at 15:08 +0100, Andrew Cooper wrote: On 17/04/18 15:02, Juergen Gross wrote: Is this something we should be aware of in Xen, too? If we had something close to a working topology representation, probably. True, as far as letting

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 04/18/2018 10:35 AM, Roger Pau Monné wrote: On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: On 04/17/2018 11:57 PM, Dongwon Kim wrote: On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: 3.2

Re: [Xen-devel] [PATCH] x86/p2m: fixed p2m_change_type_range() start / end check

On 04/18/2018 10:48 AM, Razvan Cojocaru wrote: > On 04/18/2018 10:38 AM, Jan Beulich wrote: > On 17.04.18 at 19:16, wrote: >>> --- a/xen/arch/x86/mm/p2m.c >>> +++ b/xen/arch/x86/mm/p2m.c >>> @@ -976,6 +976,13 @@ void p2m_change_type_range(struct domain *d, >>>

Re: [Xen-devel] [PATCH] x86/p2m: fixed p2m_change_type_range() start / end check

On 04/18/2018 10:38 AM, Jan Beulich wrote: On 17.04.18 at 19:16, wrote: >> --- a/xen/arch/x86/mm/p2m.c >> +++ b/xen/arch/x86/mm/p2m.c >> @@ -976,6 +976,13 @@ void p2m_change_type_range(struct domain *d, >> ASSERT(p2m_is_changeable(ot) &&

Re: [Xen-devel] [PATCH] x86/p2m: fixed p2m_change_type_range() start / end check

>>> On 17.04.18 at 19:16, wrote: > --- a/xen/arch/x86/mm/p2m.c > +++ b/xen/arch/x86/mm/p2m.c > @@ -976,6 +976,13 @@ void p2m_change_type_range(struct domain *d, > ASSERT(p2m_is_changeable(ot) && p2m_is_changeable(nt)); > > p2m_lock(p2m); > + > +if (

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: > On 04/17/2018 11:57 PM, Dongwon Kim wrote: > > On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: > > > On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: > 3.2 Backend exports dma-buf to xen-front >

Re: [Xen-devel] [PATCH] drm/xen-front: Remove CMA support

On 04/17/2018 12:08 PM, Oleksandr Andrushchenko wrote: On 04/17/2018 12:04 PM, Daniel Vetter wrote: On Tue, Apr 17, 2018 at 10:40:12AM +0300, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Even if xen-front allocates its buffers from contiguous

Re: [Xen-devel] [PATCH v7 1/9] x86/xpti: avoid copying L4 page table contents when possible

On 16/04/18 20:22, Juergen Gross wrote: > On 16/04/18 17:34, Tim Deegan wrote: >> Hi, >> >> At 02:43 -0600 on 13 Apr (1523587395), Jan Beulich wrote: >> On 12.04.18 at 20:09, wrote: For mitigation of Meltdown the current L4 page table is copied to the cpu local root

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 04/17/2018 11:57 PM, Dongwon Kim wrote: On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: Yeah, I definitely agree on the idea of expanding the use case to the general domain where dmabuf sharing is used. However,