cleanup and fix swiotlb sizing

Hi all, based on a report from Tom that overriding the default sizing provided by the x86 SEV code on the command line doesn't work anymore, this series cleans up how we handle default and command line sizes for the swiotlb buffer and then fixes the recently introduced bug in a straight-forward wa

[PATCH 2/7] swiotlb: use swiotlb_size_or_default in swiotlb_init

Use swiotlb_size_or_default to calculate the buffer size insted of open coding it. Signed-off-by: Christoph Hellwig --- kernel/dma/swiotlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index c7b3dd86db7f56..27461fd63e0330 100644

[PATCH 4/7] powerpc/pseries: simplify svm_swiotlb_init

The value returned by swiotlb_size_or_default is always properly aligned now, so don't duplicate the work. Signed-off-by: Christoph Hellwig --- arch/powerpc/platforms/pseries/svm.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/platforms/pseries/s

[PATCH 3/7] swiotlb: use swiotlb_adjust_size in setup_io_tlb_npages

Use the proper helper to do the proper alignment of the buffer size to the requirements of the swiotlb allocator instead of open coding the logic. Signed-off-by: Christoph Hellwig --- kernel/dma/swiotlb.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/kernel/dma/swio

[PATCH 5/7] MIPS/octeon: simplify swiotlb initialization

Just use swiotlb_adjust_size and swiotlb_init to initialize swiotlb instead of doing a lot of manual work. Signed-off-by: Christoph Hellwig --- arch/mips/cavium-octeon/dma-octeon.c | 16 ++-- arch/mips/include/asm/octeon/pci-octeon.h | 1 - arch/mips/pci/pci-octeon.c

[PATCH 1/7] swiotlb: pass bytes instead of nslabs to swiotlb_init_with_tbl

Pass the actual allocation size to swiotlb_init_with_tbl, which simplifies things quite a bit. Signed-off-by: Christoph Hellwig --- arch/mips/cavium-octeon/dma-octeon.c | 2 +- arch/powerpc/platforms/pseries/svm.c | 3 +-- drivers/xen/swiotlb-xen.c| 2 +- include/linux/swiotlb.h

[PATCH 7/7] swiotlb: don't override the command line in swiotlb_adjust_size

When the user specified an explicit swiotlb size on the command line, the achitecture code should not override it. Fixes: 2cbc2776efe4 ("swiotlb: remove swiotlb_nr_tbl") Reported-by: Tom Lendacky Signed-off-by: Christoph Hellwig --- kernel/dma/swiotlb.c | 6 +- 1 file changed, 5 insertions(

[PATCH 6/7] swiotlb: replace default_nslabs with a byte value

Replace the default_nslabs variable with one that stores the size in bytes as that is what all the users actually expect. Signed-off-by: Christoph Hellwig --- kernel/dma/swiotlb.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swi

Re: [PATCH 6/8] x86/EFI: avoid use of GNU ld's --disable-reloc-section when possible

On Wed, Apr 21, 2021 at 05:34:29PM +0200, Jan Beulich wrote: > On 21.04.2021 17:20, Roger Pau Monné wrote: > > On Wed, Apr 21, 2021 at 02:03:49PM +0200, Jan Beulich wrote: > >> On 21.04.2021 12:21, Roger Pau Monné wrote: > >>> On Thu, Apr 01, 2021 at 11:46:44AM +0200, Jan Beulich wrote: > @@ -

Re: [PATCH v2 3/3] docs/doxygen: doxygen documentation for grant_table.h

> On 20 Apr 2021, at 11:27, Jan Beulich wrote: > > On 20.04.2021 11:42, Luca Fancellu wrote: >>> On 20 Apr 2021, at 10:14, Jan Beulich wrote: >>> On 20.04.2021 10:46, Luca Fancellu wrote: > On 19 Apr 2021, at 12:05, Jan Beulich wrote: > On 19.04.2021 11:12, Luca Fancellu wrote: >

Re: [PATCH v4] VMX: use a single, global APIC access page

At 13:25 +0200 on 19 Apr (1618838726), Jan Beulich wrote: > On 17.04.2021 21:24, Tim Deegan wrote: > > At 12:40 +0200 on 12 Apr (1618231248), Jan Beulich wrote: > >> By making this page global, we also eliminate the need to refcount it, > >> or to assign it to any domain in the first place. > > >

Re: [PATCH 6/7] x86/shadow: Make _shadow_prealloc() compile at -Og

At 15:01 +0100 on 19 Apr (1618844491), Andrew Cooper wrote: > When compiling at -Og: > > In file included from > /builds/xen-project/people/andyhhp/xen/xen/include/asm/domain.h:4:0, >from > /builds/xen-project/people/andyhhp/xen/xen/include/xen/domain.h:8, >

Re: [PATCH v2 3/3] docs/doxygen: doxygen documentation for grant_table.h

On 22.04.2021 09:39, Luca Fancellu wrote: >> On 20 Apr 2021, at 11:27, Jan Beulich wrote: >> On 20.04.2021 11:42, Luca Fancellu wrote: On 20 Apr 2021, at 10:14, Jan Beulich wrote: On 20.04.2021 10:46, Luca Fancellu wrote: >> On 19 Apr 2021, at 12:05, Jan Beulich wrote: >> On 19

Re: [PATCH 7/8] x86/EFI: keep debug info in xen.efi

On Wed, Apr 21, 2021 at 05:38:42PM +0200, Jan Beulich wrote: > On 21.04.2021 17:30, Roger Pau Monné wrote: > > On Wed, Apr 21, 2021 at 03:06:36PM +0200, Jan Beulich wrote: > >> On 21.04.2021 13:15, Roger Pau Monné wrote: > >>> On Thu, Apr 01, 2021 at 11:47:03AM +0200, Jan Beulich wrote: > ---

[PATCH v5 00/16] Restricted DMA

This series implements mitigations for lack of DMA access control on systems without an IOMMU, which could result in the DMA accessing the system memory at unexpected times and/or unexpected addresses, possibly leading to data leakage or corruption. For example, we plan to use the PCI-e bus for Wi

[PATCH v5 01/16] swiotlb: Fix the type of index

Fix the type of index from unsigned int to int since find_slots() might return -1. Fixes: 0774983bc923 ("swiotlb: refactor swiotlb_tbl_map_single") Signed-off-by: Claire Chang --- kernel/dma/swiotlb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/dma/swiotlb.c b/ke

[PATCH v5 02/16] swiotlb: Refactor swiotlb init functions

Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct initialization to make the code reusable. Note that we now also call set_memory_decrypted in swiotlb_init_with_tbl. Signed-off-by: Claire Chang --- kernel/dma/swiotlb.c | 51 ++-- 1 fi

[PATCH v5 03/16] swiotlb: Refactor swiotlb_create_debugfs

Split the debugfs creation to make the code reusable for supporting different bounce buffer pools, e.g. restricted DMA pool. Signed-off-by: Claire Chang --- kernel/dma/swiotlb.c | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/kernel/dma/swiotlb.c b/kernel/

[PATCH v5 04/16] swiotlb: Add DMA_RESTRICTED_POOL

Add a new kconfig symbol, DMA_RESTRICTED_POOL, for restricted DMA pool. Signed-off-by: Claire Chang --- kernel/dma/Kconfig | 14 ++ 1 file changed, 14 insertions(+) diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig index 77b405508743..3e961dc39634 100644 --- a/kernel/dma/Kconfig

[PATCH v5 06/16] swiotlb: Add a new get_io_tlb_mem getter

Add a new getter, get_io_tlb_mem, to help select the io_tlb_mem struct. The restricted DMA pool is preferred if available. Signed-off-by: Claire Chang --- include/linux/swiotlb.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h in

[PATCH v5 05/16] swiotlb: Add restricted DMA pool initialization

Add the initialization function to create restricted DMA pools from matching reserved-memory nodes. Signed-off-by: Claire Chang --- include/linux/device.h | 4 +++ include/linux/swiotlb.h | 3 +- kernel/dma/swiotlb.c| 80 + 3 files changed, 86 inser

[PATCH v5 07/16] swiotlb: Update is_swiotlb_buffer to add a struct device argument

Update is_swiotlb_buffer to add a struct device argument. This will be useful later to allow for restricted DMA pool. Signed-off-by: Claire Chang --- drivers/iommu/dma-iommu.c | 12 ++-- drivers/xen/swiotlb-xen.c | 2 +- include/linux/swiotlb.h | 6 +++--- kernel/dma/direct.c |

[PATCH v5 08/16] swiotlb: Update is_swiotlb_active to add a struct device argument

Update is_swiotlb_active to add a struct device argument. This will be useful later to allow for restricted DMA pool. Signed-off-by: Claire Chang --- drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +- drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +- drivers/pci/xen-pcifront.c

[PATCH v5 09/16] swiotlb: Bounce data from/to restricted DMA pool if available

Regardless of swiotlb setting, the restricted DMA pool is preferred if available. The restricted DMA pools provide a basic level of protection against the DMA overwriting buffer contents at unexpected times. However, to protect against general data leakage and system memory corruption, the system

[PATCH v5 10/16] swiotlb: Move alloc_size to find_slots

Move the maintenance of alloc_size to find_slots for better code reusability later. Signed-off-by: Claire Chang --- kernel/dma/swiotlb.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index 96ff36d8ec53..b7d634d7a7eb 100

[PATCH v5 11/16] swiotlb: Refactor swiotlb_tbl_unmap_single

Add a new function, release_slots, to make the code reusable for supporting different bounce buffer pools, e.g. restricted DMA pool. Signed-off-by: Claire Chang --- kernel/dma/swiotlb.c | 35 --- 1 file changed, 20 insertions(+), 15 deletions(-) diff --git a/kern

[PATCH v5 12/16] dma-direct: Add a new wrapper __dma_direct_free_pages()

Add a new wrapper __dma_direct_free_pages() that will be useful later for swiotlb_free(). Signed-off-by: Claire Chang --- kernel/dma/direct.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 7a88c34d0867..7a27f051

[PATCH v5 13/16] swiotlb: Add restricted DMA alloc/free support.

Add the functions, swiotlb_{alloc,free} to support the memory allocation from restricted DMA pool. Signed-off-by: Claire Chang --- include/linux/swiotlb.h | 4 kernel/dma/swiotlb.c| 35 +-- 2 files changed, 37 insertions(+), 2 deletions(-) diff --git a/

[PATCH v5 14/16] dma-direct: Allocate memory from restricted DMA pool if available

The restricted DMA pool is preferred if available. The restricted DMA pools provide a basic level of protection against the DMA overwriting buffer contents at unexpected times. However, to protect against general data leakage and system memory corruption, the system needs to provide a way to lock

[PATCH v5 15/16] dt-bindings: of: Add restricted DMA pool

Introduce the new compatible string, restricted-dma-pool, for restricted DMA. One can specify the address and length of the restricted DMA memory region by restricted-dma-pool in the reserved-memory node. Signed-off-by: Claire Chang --- .../reserved-memory/reserved-memory.txt | 24

[PATCH v5 16/16] of: Add plumbing for restricted DMA pool

If a device is not behind an IOMMU, we look up the device node and set up the restricted DMA when the restricted-dma-pool is presented. Signed-off-by: Claire Chang --- drivers/of/address.c| 25 + drivers/of/device.c | 3 +++ drivers/of/of_private.h | 5 + 3

Re: [PATCH v4 00/14] Restricted DMA

v5 here: https://lore.kernel.org/patchwork/cover/1416899/ to rebase onto Christoph's swiotlb cleanups.

Re: [PATCH v2 14/21] libs/guest: introduce helper to check cpu policy compatibility

On Wed, Apr 14, 2021 at 03:36:54PM +0200, Jan Beulich wrote: > On 13.04.2021 16:01, Roger Pau Monne wrote: > > --- a/tools/libs/guest/xg_cpuid_x86.c > > +++ b/tools/libs/guest/xg_cpuid_x86.c > > @@ -925,3 +925,22 @@ int xc_cpu_policy_update_msrs(xc_interface *xch, > > xc_cpu_policy_t policy, > >

Re: [PATCH v2 14/21] libs/guest: introduce helper to check cpu policy compatibility

On 22.04.2021 10:22, Roger Pau Monné wrote: > On Wed, Apr 14, 2021 at 03:36:54PM +0200, Jan Beulich wrote: >> On 13.04.2021 16:01, Roger Pau Monne wrote: >>> --- a/tools/libs/guest/xg_cpuid_x86.c >>> +++ b/tools/libs/guest/xg_cpuid_x86.c >>> @@ -925,3 +925,22 @@ int xc_cpu_policy_update_msrs(xc_int

Re: Ping: [PATCH v5 0/6] evtchn: (not so) recent XSAs follow-on

On 21.04.2021 17:56, Julien Grall wrote: > > > On 21/04/2021 16:23, Jan Beulich wrote: >> On 27.01.2021 09:13, Jan Beulich wrote: >>> These are grouped into a series largely because of their origin, >>> not so much because there are (heavy) dependencies among them. >>> The main change from v4 is

Re: [PATCH v3] evtchn/fifo: don't enforce higher than necessary alignment

On 21.04.2021 21:52, Julien Grall wrote: > Hi, > > On 21/04/2021 15:36, Jan Beulich wrote: >> Neither the code nor the original commit provide any justification for >> the need to 8-byte align the struct in all cases. Enforce just as much >> alignment as the structure actually needs - 4 bytes - by

[qemu-mainline bisection] complete test-amd64-i386-xl-qemuu-debianhvm-i386-xsm

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemuu-debianhvm-i386-xsm testid guest-saverestore Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu gi

[linux-5.4 test] 161352: tolerable FAIL - PUSHED

flight 161352 linux-5.4 real [real] flight 161373 linux-5.4 real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/161352/ http://logs.test-lab.xenproject.org/osstest/logs/161373/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armh

Re: [PATCH v4] VMX: use a single, global APIC access page

On 22.04.2021 09:42, Tim Deegan wrote: > At 13:25 +0200 on 19 Apr (1618838726), Jan Beulich wrote: >> On 17.04.2021 21:24, Tim Deegan wrote: >>> At 12:40 +0200 on 12 Apr (1618231248), Jan Beulich wrote: --- a/xen/arch/x86/mm/shadow/set.c +++ b/xen/arch/x86/mm/shadow/set.c @@ -94,6 +9

Re: [PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones

On Wed, Apr 14, 2021 at 03:49:02PM +0200, Jan Beulich wrote: > On 13.04.2021 16:01, Roger Pau Monne wrote: > > @@ -944,3 +945,130 @@ bool xc_cpu_policy_is_compatible(xc_interface *xch, > > const xc_cpu_policy_t host, > > > > return false; > > } > > + > > +static uint64_t level_msr(unsigned

Re: [PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones

On 22.04.2021 11:42, Roger Pau Monné wrote: > On Wed, Apr 14, 2021 at 03:49:02PM +0200, Jan Beulich wrote: >> On 13.04.2021 16:01, Roger Pau Monne wrote: >>> @@ -944,3 +945,130 @@ bool xc_cpu_policy_is_compatible(xc_interface *xch, >>> const xc_cpu_policy_t host, >>> >>> return false; >>>

Re: [PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones

On Thu, Apr 22, 2021 at 11:58:45AM +0200, Jan Beulich wrote: > On 22.04.2021 11:42, Roger Pau Monné wrote: > > On Wed, Apr 14, 2021 at 03:49:02PM +0200, Jan Beulich wrote: > >> On 13.04.2021 16:01, Roger Pau Monne wrote: > >>> @@ -944,3 +945,130 @@ bool xc_cpu_policy_is_compatible(xc_interface *xch

[xtf test] 161363: all pass - PUSHED

flight 161363 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/161363/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf e24fbec38e66e0df8471efb0c804256bdac96636 baseline version: xtf 0395a690c921cb195619b6

Re: [PATCH 6/8] x86/EFI: avoid use of GNU ld's --disable-reloc-section when possible

On 22.04.2021 09:22, Roger Pau Monné wrote: > On Wed, Apr 21, 2021 at 05:34:29PM +0200, Jan Beulich wrote: >> On 21.04.2021 17:20, Roger Pau Monné wrote: >>> On Wed, Apr 21, 2021 at 02:03:49PM +0200, Jan Beulich wrote: On 21.04.2021 12:21, Roger Pau Monné wrote: > On Thu, Apr 01, 2021 at 1

Re: [PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones

On 22.04.2021 12:34, Roger Pau Monné wrote: > On Thu, Apr 22, 2021 at 11:58:45AM +0200, Jan Beulich wrote: >> On 22.04.2021 11:42, Roger Pau Monné wrote: >>> On Wed, Apr 14, 2021 at 03:49:02PM +0200, Jan Beulich wrote: On 13.04.2021 16:01, Roger Pau Monne wrote: > @@ -944,3 +945,130 @@ boo

Re: [PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones

On Thu, Apr 22, 2021 at 12:48:36PM +0200, Jan Beulich wrote: > On 22.04.2021 12:34, Roger Pau Monné wrote: > > On Thu, Apr 22, 2021 at 11:58:45AM +0200, Jan Beulich wrote: > >> On 22.04.2021 11:42, Roger Pau Monné wrote: > >>> On Wed, Apr 14, 2021 at 03:49:02PM +0200, Jan Beulich wrote: > On 1

Re: [PATCH 7/8] x86/EFI: keep debug info in xen.efi

On 22.04.2021 10:14, Roger Pau Monné wrote: > On Wed, Apr 21, 2021 at 05:38:42PM +0200, Jan Beulich wrote: >> On 21.04.2021 17:30, Roger Pau Monné wrote: >>> On Wed, Apr 21, 2021 at 03:06:36PM +0200, Jan Beulich wrote: On 21.04.2021 13:15, Roger Pau Monné wrote: > On Thu, Apr 01, 2021 at 1

Re: [PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones

On 22.04.2021 12:56, Roger Pau Monné wrote: > On Thu, Apr 22, 2021 at 12:48:36PM +0200, Jan Beulich wrote: >> On 22.04.2021 12:34, Roger Pau Monné wrote: >>> On Thu, Apr 22, 2021 at 11:58:45AM +0200, Jan Beulich wrote: On 22.04.2021 11:42, Roger Pau Monné wrote: > On Wed, Apr 14, 2021 at 0

Re: [PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones

On Thu, Apr 22, 2021 at 01:05:23PM +0200, Jan Beulich wrote: > On 22.04.2021 12:56, Roger Pau Monné wrote: > > On Thu, Apr 22, 2021 at 12:48:36PM +0200, Jan Beulich wrote: > >> On 22.04.2021 12:34, Roger Pau Monné wrote: > >>> On Thu, Apr 22, 2021 at 11:58:45AM +0200, Jan Beulich wrote: > On 2

Ping: [PATCH v3] x86/CPUID: shrink max_{,sub}leaf fields according to actual leaf contents

On 16.04.2021 15:16, Jan Beulich wrote: > Zapping leaf data for out of range leaves is just one half of it: To > avoid guests (bogusly or worse) inferring information from mere leaf > presence, also shrink maximum indicators such that the respective > trailing entry is not all blank (unless of cour

Re: [PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones

On 22.04.2021 13:37, Roger Pau Monné wrote: > On Thu, Apr 22, 2021 at 01:05:23PM +0200, Jan Beulich wrote: >> On 22.04.2021 12:56, Roger Pau Monné wrote: >>> On Thu, Apr 22, 2021 at 12:48:36PM +0200, Jan Beulich wrote: On 22.04.2021 12:34, Roger Pau Monné wrote: > On Thu, Apr 22, 2021 at 1

Re: [PATCH 5/9] arm/mm: Get rid of READ/WRITE_SYSREG32

Hi Julien, On 20.04.2021 15:37, Julien Grall wrote: > Hi Michal, > > On 20/04/2021 08:08, Michal Orzel wrote: >> AArch64 system registers are 64bit whereas AArch32 ones >> are 32bit or 64bit. MSR/MRS are expecting 64bit values thus >> we should get rid of helpers READ/WRITE_SYSREG32 >> in favour

Re: [PATCH v4] tools: create libxensaverestore

On 15/04/2021 14:11, Olaf Hering wrote: > Move all save/restore related code from libxenguest.so into a separate > library libxensaverestore.so. The only consumer is libxl-save-helper. "in tree consumer". It's not the only consumer, but XenServer's equivalent of libxl-save-helper is in a position

Re: [PATCH v10 01/13] x86/mm: rewrite virt_to_xen_l*e

On 21.04.2021 16:15, Hongyan Xia wrote: > From: Wei Liu > > Rewrite those functions to use the new APIs. Modify its callers to unmap > the pointer returned. Since alloc_xen_pagetable_new() is almost never > useful unless accompanied by page clearing and a mapping, introduce a > helper alloc_map_c

Re: [PATCH v10 02/13] x86/mm: switch to new APIs in map_pages_to_xen

On 21.04.2021 16:15, Hongyan Xia wrote: > From: Wei Liu > > Page tables allocated in that function should be mapped and unmapped > now. > > Take the opportunity to avoid a potential double map in > map_pages_to_xen() by initialising pl1e to NULL and only map it if it > was not mapped earlier. >

Re: [PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones

On Thu, Apr 22, 2021 at 01:42:45PM +0200, Jan Beulich wrote: > On 22.04.2021 13:37, Roger Pau Monné wrote: > > On Thu, Apr 22, 2021 at 01:05:23PM +0200, Jan Beulich wrote: > >> On 22.04.2021 12:56, Roger Pau Monné wrote: > >>> On Thu, Apr 22, 2021 at 12:48:36PM +0200, Jan Beulich wrote: > On 2

Re: [PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones

On 22.04.2021 14:07, Roger Pau Monné wrote: > On Thu, Apr 22, 2021 at 01:42:45PM +0200, Jan Beulich wrote: >> On 22.04.2021 13:37, Roger Pau Monné wrote: >>> On Thu, Apr 22, 2021 at 01:05:23PM +0200, Jan Beulich wrote: On 22.04.2021 12:56, Roger Pau Monné wrote: > On Thu, Apr 22, 2021 at 1

Re: [PATCH v4] tools: create libxensaverestore

Am Thu, 22 Apr 2021 12:49:14 +0100 schrieb Andrew Cooper : > In this form, there's a reasonable chance that it adds to the perf > problems you're trying to address. I did not benchmark this code movement. Now I wonder what the runtime cost of the move really is. The other pending series eliminat

Re: [PATCH 13/16] xen/page_alloc: add a path for xenheap when there is no direct map

On 30.04.2020 22:44, Hongyan Xia wrote: > From: Hongyan Xia > > When there is not an always-mapped direct map, xenheap allocations need > to be mapped and unmapped on-demand. > > Signed-off-by: Hongyan Xia This series has been left uncommented for far too long - I'm sorry. While earlier patche

Re: Ping: [PATCH v3] x86/CPUID: shrink max_{,sub}leaf fields according to actual leaf contents

On 22/04/2021 12:38, Jan Beulich wrote: On 16.04.2021 15:16, Jan Beulich wrote: Zapping leaf data for out of range leaves is just one half of it: To avoid guests (bogusly or worse) inferring information from mere leaf presence, also shrink maximum indicators such that the respective trailing ent

Re: Ping: [PATCH v3] x86/CPUID: shrink max_{,sub}leaf fields according to actual leaf contents

On 22.04.2021 14:34, Paul Durrant wrote: > On 22/04/2021 12:38, Jan Beulich wrote: >> On 16.04.2021 15:16, Jan Beulich wrote: >>> Zapping leaf data for out of range leaves is just one half of it: To >>> avoid guests (bogusly or worse) inferring information from mere leaf >>> presence, also shrink m

Re: [PATCH v4] tools: create libxensaverestore

Am Thu, 22 Apr 2021 12:49:14 +0100 schrieb Andrew Cooper : > That said, if you've dropped the plans for the static version, I don't > see what the point is.  You're literally saving 15 pages of memory (so > nothing in the grand scheme of a userspace process), at the cost of > added effort for the

[libvirt test] 161369: regressions - FAIL

flight 161369 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/161369/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-amd64-libvirt

Re: [PATCH v10 03/13] x86/mm: switch to new APIs in modify_xen_mappings

On Wed, 2021-04-21 at 15:15 +0100, Hongyan Xia wrote: > From: Wei Liu > > Page tables allocated in that function should be mapped and unmapped > now. > > Note that pl2e now maybe mapped and unmapped in different iterations, > so > we need to add clean-ups for that. > > Signed-off-by: Wei Liu >

Re: [PATCH 5/9] arm/mm: Get rid of READ/WRITE_SYSREG32

On 22/04/2021 12:47, Michal Orzel wrote: Hi Julien, Hi Michal, On 20.04.2021 15:37, Julien Grall wrote: Hi Michal, On 20/04/2021 08:08, Michal Orzel wrote: AArch64 system registers are 64bit whereas AArch32 ones are 32bit or 64bit. MSR/MRS are expecting 64bit values thus we should get r

[PATCH v3 00/22] xvmalloc() / x86 xstate area / x86 CPUID / AMX+XFD

While the sub-groups may seem somewhat unrelated, there are inter- dependencies (logical, functional, or contextual). The majority of the patches are unchanged in v3, but there are a few new ones. See individual patches for details. The first patch here depends on "gnttab: defer allocation of stat

[PATCH v3 01/22] mm: introduce xvmalloc() et al and use for grant table allocations

All of the array allocations in grant_table_init() can exceed a page's worth of memory, which xmalloc()-based interfaces aren't really suitable for after boot. We also don't need any of these allocations to be physically contiguous.. Introduce interfaces dynamically switching between xmalloc() et a

[PATCH v3 02/22] x86/xstate: use xvzalloc() for save area allocation

This is in preparation for the area size exceeding a page's worth of space, as will happen with AMX as well as Architectural LBR. Signed-off-by: Jan Beulich --- a/xen/arch/x86/xstate.c +++ b/xen/arch/x86/xstate.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include

[PATCH v3 03/22] x86/xstate: re-size save area when CPUID policy changes

vCPU-s get maximum size areas allocated initially. Hidden (and in particular default-off) features may allow for a smaller size area to suffice. Suggested-by: Andrew Cooper Signed-off-by: Jan Beulich --- v2: Use 1ul instead of 1ull. Re-base. --- This could be further shrunk if we used XSAVEC / i

[PATCH v3 04/22] x86/xstate: re-use valid_xcr0() for boot-time checks

Instead of (just partially) open-coding it, re-use the function after suitably moving it up. Signed-off-by: Jan Beulich --- a/xen/arch/x86/xstate.c +++ b/xen/arch/x86/xstate.c @@ -609,6 +609,34 @@ unsigned int xstate_ctxt_size(u64 xcr0) return _xstate_ctxt_size(xcr0); } +static bool vali

[PATCH v3 05/22] x86/xstate: drop xstate_offsets[] and xstate_sizes[]

They're redundant with respective fields from the raw CPUID policy; no need to keep two copies of the same data. This also breaks recalculate_xstate()'s dependency on xstate_init(), allowing host CPUID policy calculation to be moved together with that of the raw one (which a subsequent change will

[PATCH v3 06/22] x86/xstate: replace xsave_cntxt_size and drop XCNTXT_MASK

XCNTXT_MASK is effectively embedded in recalculate_xstate(), and xsave_cntxt_size was redundant with the host CPUID policy's xstate.max_size field. Use the host CPUID policy as input (requiring it to be calculated earlier), thus allowing e.g. "cpuid=no-avx512f" to also result in avoiding allocatio

[PATCH v3 07/22] x86/xstate: avoid accounting for unsupported components

There's no point in including unsupported components in the size calculations of xstate_{alloc,update}_save_area(). Signed-off-by: Jan Beulich --- a/xen/arch/x86/xstate.c +++ b/xen/arch/x86/xstate.c @@ -501,8 +501,12 @@ int xstate_alloc_save_area(struct vcpu * unsigned int i;

[PATCH v3 08/22] x86: use xvmalloc() for extended context buffer allocations

This is in preparation for the buffer sizes exceeding a page's worth of space, as will happen with AMX as well as Architectural LBR. Signed-off-by: Jan Beulich --- v2: New. --- a/xen/arch/x86/domctl.c +++ b/xen/arch/x86/domctl.c @@ -30,6 +30,7 @@ #include #include #include +#include #inc

[PATCH v3 09/22] x86/xstate: enable AMX components

These being controlled by XCR0, enabling support is relatively straightforward. Note however that there won't be any use of them until their dependent ISA extension CPUID flags get exposed, not the least due to recalculate_xstate() handling the dependencies in kind of a reverse manner. Signed-off-

[PATCH v3 10/22] x86/CPUID: adjust extended leaves out of range clearing

A maximum extended leaf input value with the high half different from 0x8000 should not be considered valid - all leaves should be cleared in this case. Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné --- TBD: Andrew suggested to drop this patch, but that sub-thread still has a loos

[PATCH v3 11/22] x86/CPUID: move bounding of max_{,sub}leaf fields to library code

Break out this logic from calculate_host_policy() to also use it in the x86 emulator harness, where subsequently we'll want to avoid open-coding AMX maximum palette bounding. Signed-off-by: Jan Beulich --- v2: New. --- a/tools/tests/x86_emulator/x86-emulate.c +++ b/tools/tests/x86_emulator/x86-e

[PATCH v3 12/22] x86/CPUID: enable AMX leaves

This requires bumping the number of basic leaves we support. Apart from this the logic is modeled as closely as possible to that of leaf 7 handling. The checks in x86_cpu_policies_are_compatible() may be more strict than they ultimately need to be, but I'd rather start being on the safe side. Sig

[PATCH v3 13/22] x86: XFD enabling

Just like for XCR0 we generally want to run with the guest settings of the involved MSRs while in Xen. Hence saving/restoring of guest values needs to only happen during context switch. While adding the feature to libxl's table I've noticed the other XSAVE sub-features all don't have entries there

[PATCH v3 14/22] x86emul: introduce X86EMUL_FPU_{tilecfg,tile}

These will be used by AMX insns. They're not sensitive to CR0.TS, but instead some are sensitive to XFD. Signed-off-by: Jan Beulich --- v3: Separate X86EMUL_FPU_tilecfg. Use XFD alternative logic instead of checking CR0.TS. v2: New. --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch

[PATCH v3 15/22] x86emul: support TILERELEASE

This is relatively straightforward, and hence best suited to introduce a few other general pieces. Testing of this will be added once a sensible test can be put together, i.e. when support for other insns is also there. Signed-off-by: Jan Beulich --- v2: New. --- a/tools/tests/x86_emulator/pred

[PATCH v3 16/22] x86: introduce struct for TILECFG register

Introduce a new x86-types.h to hold various architectural type definitions, the TILECFG register layout being the first. Arrange for the insn emulator to include this header. Signed-off-by: Jan Beulich --- v3: New. --- a/tools/fuzz/x86_instruction_emulator/Makefile +++ b/tools/fuzz/x86_instructi

[PATCH v3 17/22] x86emul: support {LD,ST}TILECFG

While ver 043 of the ISA extensions doc also specifies xcr0_supports_palette() returning false as one of the #GP(0) reasons for LDTILECFG, the earlier #UD / #GP conditions look to make this fully dead. Signed-off-by: Jan Beulich --- v3: Rebase over struct x86_tilecfg introduction. v2: New. --- SD

[PATCH v3 18/22] x86emul: support TILEZERO

This is relatively straightforward, and hence best suited to introduce a few other wider use pieces. Testing of this will be added once a sensible test can be put together, i.e. when support for at least TILELOADD (to allow loading non-zero values in the first place) is also there. Signed-off-by:

[xen-unstable-smoke test] 161377: tolerable all pass - PUSHED

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

[PATCH v3 19/22] x86emul: support TILELOADD{,T1} and TILESTORE

In order to be flexible about future growth of tile dimensions, use a separately allocated scratch buffer to read/write individual rows of a tile. Note that the separate write_tilecfg() function is needed because LDTILECFG wouldn't serve the purpose: It clears various state, unlike XRSTOR / XRSTOR

[PATCH v3 20/22] x86emul: support tile multiplication insns

Since these don't allow for memory operands, the main thing to do here is to check the large set of #UD conditions. Signed-off-by: Jan Beulich --- v3: New. --- a/tools/tests/x86_emulator/predicates.c +++ b/tools/tests/x86_emulator/predicates.c @@ -1349,6 +1349,11 @@ static const struct vex {

Re: [PATCH 7/8] x86/EFI: keep debug info in xen.efi

On Thu, Apr 22, 2021 at 01:03:13PM +0200, Jan Beulich wrote: > On 22.04.2021 10:14, Roger Pau Monné wrote: > > On Wed, Apr 21, 2021 at 05:38:42PM +0200, Jan Beulich wrote: > >> On 21.04.2021 17:30, Roger Pau Monné wrote: > >>> On Wed, Apr 21, 2021 at 03:06:36PM +0200, Jan Beulich wrote: > On 2

[PATCH v3 21/22] x86emul: test AMX insns

Carry out some basic matrix operations on 2x2, 3x3, and 4x4 matrixes. To also have a use of a non-square matrix, also transpose ones of said square formats via linearization and multiplication by the respective transposition permutation matrix. To generate the latter, introduce a small helper tool

[PATCH v3 22/22] x86: permit guests to use AMX and XFD

These features are marked experimental (for only parts of the code actually having got tested yet, while other parts require respective hardware) and opt-in for guests. Signed-off-by: Jan Beulich --- v3: New. --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -6,6 +6,9 @@ The format is based on [Keep a Ch

Re: [PATCH v4] VMX: use a single, global APIC access page

At 11:38 +0200 on 22 Apr (1619091522), Jan Beulich wrote: > On 22.04.2021 09:42, Tim Deegan wrote: > > At 13:25 +0200 on 19 Apr (1618838726), Jan Beulich wrote: > >> On 17.04.2021 21:24, Tim Deegan wrote: > >>> At 12:40 +0200 on 12 Apr (1618231248), Jan Beulich wrote: > --- a/xen/arch/x86/mm/s

Re: [PATCH v3 19/22] x86emul: support TILELOADD{,T1} and TILESTORE

Paul, On 22.04.2021 16:55, Jan Beulich wrote: > +do { > +/* Limit rows to just as many to cover the next one to access. */ > +cfg->start_row = i; > +cfg->rows[modrm_reg] = i + 1; > +write_tilecfg(cfg); > + > +if ( vex.pfx != vex_f

[PATCH 3/3] xen: assume XENFEAT_gnttab_map_avail_bits being set for pv guests

XENFEAT_gnttab_map_avail_bits is always set in Xen 4.0 and newer. Remove coding assuming it might be zero. Signed-off-by: Juergen Gross --- drivers/xen/gntdev.c | 36 ++-- 1 file changed, 2 insertions(+), 34 deletions(-) diff --git a/drivers/xen/gntdev.c b/driver

[PATCH 0/3] xen: remove some checks for always present Xen features

Some features of Xen can be assumed to be always present, so add a central check to verify this being true and remove the other checks. Juergen Gross (3): xen: check required Xen features xen: assume XENFEAT_mmu_pt_update_preserve_ad being set for pv guests xen: assume XENFEAT_gnttab_map_ava

[PATCH 2/3] xen: assume XENFEAT_mmu_pt_update_preserve_ad being set for pv guests

XENFEAT_mmu_pt_update_preserve_ad is always set in Xen 4.0 and newer. Remove coding assuming it might be zero. Signed-off-by: Juergen Gross --- arch/x86/xen/enlighten_pv.c | 12 ++-- arch/x86/xen/mmu_pv.c | 4 ++-- 2 files changed, 4 insertions(+), 12 deletions(-) diff --git a/ar

[PATCH 1/3] xen: check required Xen features

Linux kernel is not supported to run on Xen versions older than 4.0. Add tests for required Xen features always being present in Xen 4.0 and newer. Signed-off-by: Juergen Gross --- drivers/xen/features.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/xen/feature

Re: [PATCH v3 19/22] x86emul: support TILELOADD{,T1} and TILESTORE

On 22.04.2021 17:06, Jan Beulich wrote: > On 22.04.2021 16:55, Jan Beulich wrote: >> +do { >> +/* Limit rows to just as many to cover the next one to access. >> */ >> +cfg->start_row = i; >> +cfg->rows[modrm_reg] = i + 1; >> +write_tilecfg(cf

Re: [PATCH 0/3] xen: remove some checks for always present Xen features

On 22.04.2021 17:10, Juergen Gross wrote: > Some features of Xen can be assumed to be always present, so add a > central check to verify this being true and remove the other checks. > > Juergen Gross (3): > xen: check required Xen features > xen: assume XENFEAT_mmu_pt_update_preserve_ad being

Re: [PATCH 0/3] xen: remove some checks for always present Xen features

On 22.04.21 17:16, Jan Beulich wrote: On 22.04.2021 17:10, Juergen Gross wrote: Some features of Xen can be assumed to be always present, so add a central check to verify this being true and remove the other checks. Juergen Gross (3): xen: check required Xen features xen: assume XENFEAT_m

Re: [PATCH 0/3] xen: remove some checks for always present Xen features

On 22.04.2021 17:17, Juergen Gross wrote: > On 22.04.21 17:16, Jan Beulich wrote: >> On 22.04.2021 17:10, Juergen Gross wrote: >>> Some features of Xen can be assumed to be always present, so add a >>> central check to verify this being true and remove the other checks. >>> >>> Juergen Gross (3): >

  1   2   >