[PATCH v2 2/2] x86/AMD: drop MSR_K7_HWCR

We don't support any K7 (32-bit only) hardware anymore, and the MSR is accessible as MSR_K8_HWCR as well. Using the K7 name was particularly odd for Hygon as well as in a Fam0F-specific piece of code. Signed-off-by: Jan Beulich --- v2: New. --- Of course there are more MSR_K7_* left - we'll have

[PATCH v2 1/2] x86/AMD: expose SYSCFG, TOM, TOM2, and IORRs to Dom0

Sufficiently old Linux (3.12-ish) accesses these MSRs (with the exception of IORRs) in an unguarded manner. Furthermore these same MSRs, at least on Fam11 and older CPUs, are also consulted by modern Linux, and their (bogus) built-in zapping of #GP faults from MSR accesses leads to it effectively r

[PATCH v2 0/2] x86/AMD: MSR handling adjustments

1: expose SYSCFG, TOM, TOM2, and IORRs to Dom0 2: drop MSR_K7_HWCR Jan

Re: [PATCH 04/13] cpufreq: Add Hardware P-State (HWP) driver

On 27.05.2021 20:50, Jason Andryuk wrote: > On Wed, May 26, 2021 at 11:00 AM Jan Beulich wrote: >> >> On 03.05.2021 21:28, Jason Andryuk wrote: >>> If HWP Energy_Performance_Preference isn't supported, the code falls >>> back to IA32_ENERGY_PERF_BIAS. Right now, we don't check >>> CPUID.06H:ECX.S

[libvirt test] 162243: regressions - FAIL

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

[qemu-mainline test] 162240: regressions - FAIL

flight 162240 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/162240/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-am

[xen-unstable test] 162230: tolerable FAIL

flight 162230 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/162230/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 162172 test-armhf-armhf-libvirt 16 save

Re: [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default

On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote: > Goes through all the drivers and deletes the default hook since it's > the default now. > > Signed-off-by: Daniel Vetter > Cc: Joel Stanley > Cc: Andrew Jeffery > Cc: "Noralf Trønnes" > Cc: Linus Walleij > Cc: Emma Anholt > Cc: David L

[linux-linus test] 162209: regressions - FAIL

flight 162209 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/162209/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i3

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

flight 162239 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/162239/ 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

[ovmf test] 162217: all pass - PUSHED

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

[qemu-mainline test] 162197: regressions - FAIL

flight 162197 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/162197/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i3

Re: [PATCH 04/13] cpufreq: Add Hardware P-State (HWP) driver

On Wed, May 26, 2021 at 11:00 AM Jan Beulich wrote: > > On 03.05.2021 21:28, Jason Andryuk wrote: > > If HWP Energy_Performance_Preference isn't supported, the code falls > > back to IA32_ENERGY_PERF_BIAS. Right now, we don't check > > CPUID.06H:ECX.SETBH[bit 3] before using that MSR. > > May I a

Re: [PATCH v6 1/3] evtchn: slightly defer lock acquire where possible

Hi Jan, On 27/05/2021 12:28, Jan Beulich wrote: port_is_valid() and evtchn_from_port() are fine to use without holding any locks. Accordingly acquire the per-domain lock slightly later in evtchn_close() and evtchn_bind_vcpu(). So I agree that port_is_valid() and evtchn_from_port() are fine to

Design Session: Using Gitlab MR for Xen

Hello, Attached are the notes and public chat record for the Design Session: Using Gitlab MR for Xen. Thanks, Deb Deb Giles Event Manager The Linux Foundation +1.503.807.1876 (Time Zone: Central Time) *Schedule a Meeting with Me* [11:45] Welcome to

Re: [PATCH 3/3] x86/tsx: Deprecate vpmu=rtm-abort and use tsx= instead

On 27/05/2021 18:24, Roger Pau Monné wrote: > On Thu, May 27, 2021 at 02:25:19PM +0100, Andrew Cooper wrote: >> This reuses the rtm_disable infrastructure, so CPUID derivation works >> properly >> when TSX is disabled in favour of working PCR3. >> >> vpmu= is not a supported feature, and having th

Design Session Notes

Hi Everyone, Attached are the notes from the Design Session on VirtuIO Cross-Project BoF (Birds of a Feather) for Xen and Guest OS (Linux, Windows, FreeBSD) developers. Thanks, Deb Deb Giles Event Manager The Linux Foundation +1.503.807.1876 (Time Zone: Central Time) *Schedule a Meeting with M

Re: [PATCH] x86/AMD: expose SYSCFG, TOM, and TOM2 to Dom0

On Thu, May 27, 2021 at 04:57:04PM +0200, Jan Beulich wrote: > On 27.05.2021 15:23, Roger Pau Monné wrote: > > On Thu, May 27, 2021 at 12:41:51PM +0200, Jan Beulich wrote: > >> On 27.05.2021 10:33, Roger Pau Monné wrote: > >>> On Wed, May 26, 2021 at 02:59:00PM +0200, Jan Beulich wrote: > Suff

Re: [PATCH 3/3] x86/tsx: Deprecate vpmu=rtm-abort and use tsx= instead

On Thu, May 27, 2021 at 02:25:19PM +0100, Andrew Cooper wrote: > This reuses the rtm_disable infrastructure, so CPUID derivation works properly > when TSX is disabled in favour of working PCR3. > > vpmu= is not a supported feature, and having this functionality under tsx= > centralises all TSX han

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

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

Re: [PATCH v7 01/15] swiotlb: Refactor swiotlb init functions

On 5/27/21 9:41 AM, Tom Lendacky wrote: > On 5/27/21 8:02 AM, Christoph Hellwig wrote: >> On Wed, May 19, 2021 at 11:50:07AM -0700, Florian Fainelli wrote: >>> You convert this call site with swiotlb_init_io_tlb_mem() which did not >>> do the set_memory_decrypted()+memset(). Is this okay or should

Re: [PATCH 2/3] x86/tsx: Minor cleanup and improvements

On Thu, May 27, 2021 at 02:25:18PM +0100, Andrew Cooper wrote: > * Introduce cpu_has_arch_caps and replace boot_cpu_has(X86_FEATURE_ARCH_CAPS) > * Read CPUID data into the appropriate boot_cpu_data.x86_capability[] >element, as subsequent changes are going to need more cpu_has_* logic. > * U

Re: [PATCH 1/3] x86/cpuid: Rework HLE and RTM handling

On Thu, May 27, 2021 at 02:25:17PM +0100, Andrew Cooper wrote: > The TAA mitigation offered the option to hide the HLE and RTM CPUID bits, > which has caused some migration compatibility problems. > > These two bits are special. Annotate them with ! to emphasise this point. > > Hardware Lock Eli

Re: [PATCH 3/3] x86/tsx: Deprecate vpmu=rtm-abort and use tsx= instead

On 27.05.2021 15:25, Andrew Cooper wrote: > This reuses the rtm_disable infrastructure, so CPUID derivation works properly > when TSX is disabled in favour of working PCR3. > > vpmu= is not a supported feature, and having this functionality under tsx= > centralises all TSX handling. > > Signed-of

Re: [PATCH 2/3] x86/tsx: Minor cleanup and improvements

On 27.05.2021 15:25, Andrew Cooper wrote: > * Introduce cpu_has_arch_caps and replace boot_cpu_has(X86_FEATURE_ARCH_CAPS) > * Read CPUID data into the appropriate boot_cpu_data.x86_capability[] >element, as subsequent changes are going to need more cpu_has_* logic. > * Use the hi/lo MSR help

Re: [PATCH 1/3] x86/cpuid: Rework HLE and RTM handling

On 27.05.2021 15:25, Andrew Cooper wrote: > The TAA mitigation offered the option to hide the HLE and RTM CPUID bits, > which has caused some migration compatibility problems. > > These two bits are special. Annotate them with ! to emphasise this point. > > Hardware Lock Elision (HLE) may or may

Re: [PATCH v2 01/12] x86: introduce ioremap_wc()

On 27.05.2021 15:30, Julien Grall wrote: > On 27/05/2021 14:09, Jan Beulich wrote: >> On 27.05.2021 14:48, Julien Grall wrote: >>> On 27/05/2021 13:30, Jan Beulich wrote: --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -5881,6 +5881,20 @@ void __iomem *ioremap(paddr_t pa, size_t >

Re: [PATCH] x86/AMD: expose SYSCFG, TOM, and TOM2 to Dom0

On 27.05.2021 15:23, Roger Pau Monné wrote: > On Thu, May 27, 2021 at 12:41:51PM +0200, Jan Beulich wrote: >> On 27.05.2021 10:33, Roger Pau Monné wrote: >>> On Wed, May 26, 2021 at 02:59:00PM +0200, Jan Beulich wrote: Sufficiently old Linux (3.12-ish) accesses these MSRs in an unguarded

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

flight 162175 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/162175/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 162123 test-amd64-amd64-xl-qemut-win7-amd64 19

Re: [PATCH v7 01/15] swiotlb: Refactor swiotlb init functions

On 5/27/21 8:02 AM, Christoph Hellwig wrote: > On Wed, May 19, 2021 at 11:50:07AM -0700, Florian Fainelli wrote: >> You convert this call site with swiotlb_init_io_tlb_mem() which did not >> do the set_memory_decrypted()+memset(). Is this okay or should >> swiotlb_init_io_tlb_mem() add an additiona

Re: [PATCH -next 2/3] xen: balloon: Replaced simple_strtoull() with kstrtoull()

On Thu, May 27, 2021 at 02:10:21PM +, David Laight wrote: > From: Chen Huang > > Sent: 26 May 2021 10:20 > > > > The simple_strtoull() function is deprecated in some situation, since > > it does not check for the range overflow, use kstrtoull() instead. > > > ... > > - target_bytes = simple

RE: [PATCH -next 2/3] xen: balloon: Replaced simple_strtoull() with kstrtoull()

From: Chen Huang > Sent: 26 May 2021 10:20 > > The simple_strtoull() function is deprecated in some situation, since > it does not check for the range overflow, use kstrtoull() instead. > ... > - target_bytes = simple_strtoull(buf, &endchar, 0) * 1024; > + ret = kstrtoull(buf, 0, &target_

Re: [PATCH v2 07/12] mm: allow page scrubbing routine(s) to be arch controlled

On 27.05.2021 15:06, Julien Grall wrote: > On 27/05/2021 13:33, Jan Beulich wrote: >> Especially when dealing with large amounts of memory, memset() may not >> be very efficient; this can be bad enough that even for debug builds a >> custom function is warranted. We additionally want to distinguish

[libvirt test] 162191: regressions - FAIL

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

Re: [PATCH v6 3/3] evtchn: type adjustments

On Thu, May 27, 2021 at 01:28:59PM +0200, Jan Beulich wrote: > First of all avoid "long" when "int" suffices, i.e. in particular when > merely conveying error codes. 32-bit values are slightly cheaper to > deal with on x86, and their processing is at least no more expensive on > Arm. Where possible

Re: [PATCH v6 1/3] evtchn: slightly defer lock acquire where possible

On Thu, May 27, 2021 at 01:28:07PM +0200, Jan Beulich wrote: > port_is_valid() and evtchn_from_port() are fine to use without holding > any locks. Accordingly acquire the per-domain lock slightly later in > evtchn_close() and evtchn_bind_vcpu(). > > Signed-off-by: Jan Beulich Acked-by: Roger Pau

Re: [PATCH v8 00/15] Restricted DMA

I just finished reviewing v7, sorry. Let me find some time to see what difference this version makes.

Re: [PATCH v7 13/15] dma-direct: Allocate memory from restricted DMA pool if available

> +#ifdef CONFIG_DMA_RESTRICTED_POOL > + if (swiotlb_free(dev, page, size)) > + return; > +#endif Please avoid the ifdefs by either stubbing out the function to be a no-op or by using IS_ENABLED. > +#ifdef CONFIG_DMA_RESTRICTED_POOL > + page = swiotlb_alloc(dev, size); > +

Re: [PATCH v2 01/12] x86: introduce ioremap_wc()

Hi Jan, On 27/05/2021 14:09, Jan Beulich wrote: On 27.05.2021 14:48, Julien Grall wrote: On 27/05/2021 13:30, Jan Beulich wrote: --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -5881,6 +5881,20 @@ void __iomem *ioremap(paddr_t pa, size_t return (void __force __iomem *)va; } +v

Re: [PATCH v7 07/15] swiotlb: Update is_swiotlb_active to add a struct device argument

> + if (is_swiotlb_active(NULL)) { Passing a NULL argument to this doesn't make sense. They all should have a struct device at hand, you'll just need to dig for it. And this function should be about to go away anyway, but until then we need to do this properly.

Re: [PATCH v7 04/15] swiotlb: Add restricted DMA pool initialization

I'd still much prefer to always have the pointer in struct device. Especially as we're also looking into things like a global 64-bit bounce buffer. Something like this untested patch ontop of your series: diff --git a/drivers/base/core.c b/drivers/base/core.c index 628e33939aca..3cb95fa29f70 100

Re: [PATCH v7 04/15] swiotlb: Add restricted DMA pool initialization

On Mon, May 24, 2021 at 11:49:34AM -0400, Konrad Rzeszutek Wilk wrote: > rmem_swiotlb_setup > > ? > > Which is ARM specific and inside the generic code? I don't think it is arm specific at all. It is OF specific, but just about every platform but x86 uses OF. And I can think of an ACPI version

[PATCH 3/3] x86/tsx: Deprecate vpmu=rtm-abort and use tsx= instead

This reuses the rtm_disable infrastructure, so CPUID derivation works properly when TSX is disabled in favour of working PCR3. vpmu= is not a supported feature, and having this functionality under tsx= centralises all TSX handling. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau

[PATCH 0/3] x86: Fixes to TSX handling

Fix the handling of the HLE/RTM CPUID bits for guests. Andrew Cooper (3): x86/cpuid: Rework HLE and RTM handling x86/tsx: Minor cleanup and improvements x86/tsx: Deprecate vpmu=rtm-abort and use tsx= instead docs/misc/xen-command-line.pandoc | 40 +-- tools/libs/guest/xg

[PATCH 2/3] x86/tsx: Minor cleanup and improvements

* Introduce cpu_has_arch_caps and replace boot_cpu_has(X86_FEATURE_ARCH_CAPS) * Read CPUID data into the appropriate boot_cpu_data.x86_capability[] element, as subsequent changes are going to need more cpu_has_* logic. * Use the hi/lo MSR helpers, which substantially improves code generation.

[PATCH 1/3] x86/cpuid: Rework HLE and RTM handling

The TAA mitigation offered the option to hide the HLE and RTM CPUID bits, which has caused some migration compatibility problems. These two bits are special. Annotate them with ! to emphasise this point. Hardware Lock Elision (HLE) may or may not be visible in CPUID, but is disabled in microcode

Re: [PATCH v7 03/15] swiotlb: Add DMA_RESTRICTED_POOL

On Tue, May 18, 2021 at 02:42:03PM +0800, Claire Chang wrote: > Add a new kconfig symbol, DMA_RESTRICTED_POOL, for restricted DMA pool. Please merge this with the actual code that is getting added.

Re: [PATCH v7 02/15] swiotlb: Refactor swiotlb_create_debugfs

On Tue, May 18, 2021 at 02:42:02PM +0800, Claire Chang wrote: > struct io_tlb_mem *io_tlb_default_mem; > +static struct dentry *debugfs_dir; > > /* > * Max segment that we can provide which (if pages are contingous) will > @@ -662,18 +663,30 @@ EXPORT_SYMBOL_GPL(is_swiotlb_active); > > #if

Re: [PATCH] x86/AMD: expose SYSCFG, TOM, and TOM2 to Dom0

On Thu, May 27, 2021 at 12:41:51PM +0200, Jan Beulich wrote: > On 27.05.2021 10:33, Roger Pau Monné wrote: > > On Wed, May 26, 2021 at 02:59:00PM +0200, Jan Beulich wrote: > >> Sufficiently old Linux (3.12-ish) accesses these MSRs in an unguarded > >> manner. Furthermore these MSRs, at least on Fam

[PATCH v8 15/15] 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| 33 + drivers/of/device.c | 3 +++ drivers/of/of_private.h | 6 +

Re: [PATCH v2 01/12] x86: introduce ioremap_wc()

On 27.05.2021 14:48, Julien Grall wrote: > On 27/05/2021 13:30, Jan Beulich wrote: >> --- a/xen/arch/x86/mm.c >> +++ b/xen/arch/x86/mm.c >> @@ -5881,6 +5881,20 @@ void __iomem *ioremap(paddr_t pa, size_t >> return (void __force __iomem *)va; >> } >> >> +void __iomem *__init ioremap_wc(pa

Re: [PATCH v2 07/12] mm: allow page scrubbing routine(s) to be arch controlled

Hi Jan, On 27/05/2021 13:33, Jan Beulich wrote: Especially when dealing with large amounts of memory, memset() may not be very efficient; this can be bad enough that even for debug builds a custom function is warranted. We additionally want to distinguish "hot" and "cold" cases. Do you have an

[PATCH v8 14/15] 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 | 36

[PATCH v8 13/15] 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 v8 12/15] 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 v8 10/15] 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 v8 11/15] 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 078f7087e466..eb409832

[PATCH v8 08/15] 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

Re: [PATCH v7 00/15] Restricted DMA

v8 here: https://lore.kernel.org/patchwork/cover/1437112/

[PATCH v8 09/15] 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 fa7f23fffc81..88b3471ac6a8 100

Re: [PATCH v7 01/15] swiotlb: Refactor swiotlb init functions

On Wed, May 19, 2021 at 11:50:07AM -0700, Florian Fainelli wrote: > You convert this call site with swiotlb_init_io_tlb_mem() which did not > do the set_memory_decrypted()+memset(). Is this okay or should > swiotlb_init_io_tlb_mem() add an additional argument to do this > conditionally? The zeroin

[PATCH v8 07/15] 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 v8 06/15] 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 v8 05/15] 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. The reason it was done this way instead of assigning the active pool to dev->dma_io_tlb_mem was because directly using dev->dma_io_tlb_mem might cause memory allocation issues

[PATCH v8 04/15] 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| 76 + 3 files changed, 82 inser

[PATCH v8 03/15] 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 v8 02/15] 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 | 25 +++-- 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/kernel/dma/swiotlb.c b/

[PATCH v8 01/15] 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 v8 00/15] 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

[xen-unstable test] 162172: tolerable FAIL - PUSHED

flight 162172 xen-unstable real [real] flight 16 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/162172/ http://logs.test-lab.xenproject.org/osstest/logs/16/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd6

[XEN PATCH v2] libxl/arm: provide guests with random seed

Pass 128 bytes of random seed via FDT, so that guests' CRNGs are better seeded early at boot. This is larger than ChaCha20 key size of 32, so each byte of CRNG state will be mixed 4 times using this seed. There does not seem to be advantage in larger seed though. Depending on its configuration Lin

Re: [PATCH v7 14/15] dt-bindings: of: Add restricted DMA pool

On Thu, May 27, 2021 at 08:48:59PM +0800, Claire Chang wrote: > On Thu, May 27, 2021 at 7:35 PM Will Deacon wrote: > > > > On Thu, May 27, 2021 at 07:29:20PM +0800, Claire Chang wrote: > > > On Wed, May 26, 2021 at 11:53 PM Will Deacon wrote: > > > > > > > > On Wed, May 26, 2021 at 01:13:22PM +01

Re: [PATCH v7 14/15] dt-bindings: of: Add restricted DMA pool

On Thu, May 27, 2021 at 7:35 PM Will Deacon wrote: > > On Thu, May 27, 2021 at 07:29:20PM +0800, Claire Chang wrote: > > On Wed, May 26, 2021 at 11:53 PM Will Deacon wrote: > > > > > > On Wed, May 26, 2021 at 01:13:22PM +0100, Will Deacon wrote: > > > > On Tue, May 18, 2021 at 02:42:14PM +0800, C

Re: [PATCH v2 01/12] x86: introduce ioremap_wc()

Hi Jan, On 27/05/2021 13:30, Jan Beulich wrote: In order for a to-be-introduced ERMS form of memcpy() to not regress boot performance on certain systems when video output is active, we first need to arrange for avoiding further dependency on firmware setting up MTRRs in a way we can actually fur

[PATCH v2 12/12] video/vesa: adjust (not just) command line option handling

Document the remaining option. Add section annotation to the variable holding the parsed value as well as a few adjacent ones. Adjust the types of font_height and vga_compat. Signed-off-by: Jan Beulich Acked-by: Andrew Cooper --- v2: Re-base over added earlier patch. --- a/docs/misc/xen-command

[PATCH v2 11/12] video/vesa: drop "vesa-remap" command line option

If we get mode dimensions wrong, having the remapping size controllable via command line option isn't going to help much. Drop the option. While adjusting this also - add __initdata to the variable, - use ROUNDUP() instead of open-coding it. Requested-by: Andrew Cooper Signed-off-by: Jan Beulich

[PATCH v2 10/12] video/vesa: drop "vesa-mtrr" command line option

Now that we use ioremap_wc() for mapping the frame buffer, there's no need for this option anymore. As noted in the change introducing the use of ioremap_wc(), mtrr_add() didn't work in certain cases anyway. Signed-off-by: Jan Beulich Acked-by: Andrew Cooper --- a/CHANGELOG.md +++ b/CHANGELOG.m

[PATCH v2 09/12] video/vesa: unmap frame buffer when relinquishing console

There's no point in keeping the VA space occupied when no further output will occur. Signed-off-by: Jan Beulich --- a/xen/drivers/video/lfb.c +++ b/xen/drivers/video/lfb.c @@ -168,4 +168,5 @@ void lfb_free(void) xfree(lfb.lbuf); xfree(lfb.text_buf); xfree(lfb.line_len); +lfb.l

[PATCH v2 08/12] x86: move .text.kexec

The source file requests page alignment - avoid a padding hole by placing it right after .text.entry. On average this yields a .text size reduction of 2k. Requested-by: Andrew Cooper Signed-off-by: Jan Beulich --- v2: New. --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -83,10 +83,

[PATCH v2 07/12] mm: allow page scrubbing routine(s) to be arch controlled

Especially when dealing with large amounts of memory, memset() may not be very efficient; this can be bad enough that even for debug builds a custom function is warranted. We additionally want to distinguish "hot" and "cold" cases. Keep the default fallback to clear_page_*() in common code; this m

[PATCH v2 06/12] page-alloc: make scrub_on_page() static

Before starting to alter its properties, restrict the function's visibility. The only external user is mem-paging, which we can accommodate by different means. Also move the function up in its source file, so we won't need to forward-declare it. Constify its parameter at the same time. Signed-off

[PATCH v2 05/12] x86: introduce "hot" and "cold" page clearing functions

The present clear_page_sse2() is useful in case a page isn't going to get touched again soon, or if we want to limit churn on the caches. Amend it by alternatively using CLZERO, which has been found to be quite a bit faster on Zen2 hardware at least. Note that to use CLZERO, we need to know the cac

[PATCH v2 04/12] x86: control memset() and memcpy() inlining

Stop the compiler from inlining non-trivial memset() and memcpy() (for memset() see e.g. map_vcpu_info() or kimage_load_segments() for examples). This way we even keep the compiler from using REP STOSQ / REP MOVSQ when we'd prefer REP STOSB / REP MOVSB (when ERMS is available). With gcc10 this yie

[PATCH v2 02/12] x86: re-work memset()

Move the function to its own assembly file. Having it in C just for the entire body to be an asm() isn't really helpful. Then have two flavors: A "basic" version using qword steps for the bulk of the operation, and an ERMS version for modern hardware, to be substituted in via alternatives patching.

[PATCH v2 03/12] x86: re-work memcpy()

Move the function to its own assembly file. Having it in C just for the entire body to be an asm() isn't really helpful. Then have two flavors: A "basic" version using qword steps for the bulk of the operation, and an ERMS version for modern hardware, to be substituted in via alternatives patching.

[PATCH v2 01/12] x86: introduce ioremap_wc()

In order for a to-be-introduced ERMS form of memcpy() to not regress boot performance on certain systems when video output is active, we first need to arrange for avoiding further dependency on firmware setting up MTRRs in a way we can actually further modify. On many systems, due to the continuous

[PATCH v2 00/12] x86: memcpy() / memset() (non-)ERMS flavors plus fallout

While the performance varies quite a bit on older (pre-ERMS) and newer (ERMS) hardware, so far we've been going with just a single flavor of these two functions, and oddly enough with ones not consistent with one another. Using plain memcpy() / memset() on MMIO (video frame buffer) is generally oka

Re: [PATCH 7/7] video/vesa: adjust (not just) command line option handling

On 27.04.2021 16:04, Jan Beulich wrote: > On 27.04.2021 15:49, Andrew Cooper wrote: >> However, is there really any value in these options?  I can't see a case >> where their use will result in a less broken system. > > Well, if we mis-detect VRAM size, the respective option might indeed > help. I

Re: [PATCH v7 14/15] dt-bindings: of: Add restricted DMA pool

On Wed, May 26, 2021 at 11:53 PM Will Deacon wrote: > > On Wed, May 26, 2021 at 01:13:22PM +0100, Will Deacon wrote: > > On Tue, May 18, 2021 at 02:42:14PM +0800, Claire Chang wrote: > > > @@ -138,4 +160,9 @@ one for multimedia processing (named > > > multimedia-memory@7700, 64MiB). > > >

Re: [PATCH v7 14/15] dt-bindings: of: Add restricted DMA pool

On Thu, May 27, 2021 at 07:29:20PM +0800, Claire Chang wrote: > On Wed, May 26, 2021 at 11:53 PM Will Deacon wrote: > > > > On Wed, May 26, 2021 at 01:13:22PM +0100, Will Deacon wrote: > > > On Tue, May 18, 2021 at 02:42:14PM +0800, Claire Chang wrote: > > > > @@ -138,4 +160,9 @@ one for multimedi

[PATCH v6 3/3] evtchn: type adjustments

First of all avoid "long" when "int" suffices, i.e. in particular when merely conveying error codes. 32-bit values are slightly cheaper to deal with on x86, and their processing is at least no more expensive on Arm. Where possible use evtchn_port_t for port numbers and unsigned int for other unsign

[PATCH v6 2/3] evtchn: add helper for port_is_valid() + evtchn_from_port()

The combination is pretty common, so adding a simple local helper seems worthwhile. Make it const- and type-correct, in turn requiring the two called function to also be const-correct (and at this occasion also make them type-correct). Signed-off-by: Jan Beulich Acked-by: Julien Grall --- v6: Re

[PATCH v6 1/3] evtchn: slightly defer lock acquire where possible

port_is_valid() and evtchn_from_port() are fine to use without holding any locks. Accordingly acquire the per-domain lock slightly later in evtchn_close() and evtchn_bind_vcpu(). Signed-off-by: Jan Beulich --- v6: Re-base for re-ordering / shrinking of series. v4: New. --- a/xen/common/event_cha

[PATCH v6 0/3] evtchn: (not so) recent XSAs follow-on

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 v6 is the dropping of three more patches, and re-basing. 1: slightly defer lock acquire where possible 2: add helper for port_is_valid() + evtchn_fro

Re: [PATCH v5 2/6] evtchn: convert domain event lock to an r/w one

On 27.05.2021 13:01, Roger Pau Monné wrote: > On Wed, Jan 27, 2021 at 09:16:07AM +0100, Jan Beulich wrote: >> Especially for the use in evtchn_move_pirqs() (called when moving a vCPU >> across pCPU-s) and the ones in EOI handling in PCI pass-through code, >> serializing perhaps an entire domain isn

Re: [PATCH v5 2/6] evtchn: convert domain event lock to an r/w one

On Wed, Jan 27, 2021 at 09:16:07AM +0100, Jan Beulich wrote: > Especially for the use in evtchn_move_pirqs() (called when moving a vCPU > across pCPU-s) and the ones in EOI handling in PCI pass-through code, > serializing perhaps an entire domain isn't helpful when no state (which > isn't e.g. furt

Re: [PATCH] x86/AMD: expose SYSCFG, TOM, and TOM2 to Dom0

On 27.05.2021 10:33, Roger Pau Monné wrote: > On Wed, May 26, 2021 at 02:59:00PM +0200, Jan Beulich wrote: >> Sufficiently old Linux (3.12-ish) accesses these MSRs in an unguarded >> manner. Furthermore these MSRs, at least on Fam11 and older CPUs, are >> also consulted by modern Linux, and their (

Re: [PATCH] x86: make hypervisor build with gcc11

On 27.05.2021 10:48, Roger Pau Monné wrote: > On Wed, May 19, 2021 at 05:39:50PM +0200, Jan Beulich wrote: >> Gcc 11 looks to make incorrect assumptions about valid ranges that >> pointers may be used for addressing when they are derived from e.g. a >> plain constant. See https://gcc.gnu.org/bugzil

Re: [PATCH 13/13] CHANGELOG: Add Intel HWP entry

On 03.05.2021 21:28, Jason Andryuk wrote: > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -5,6 +5,8 @@ Notable changes to Xen will be documented in this file. > The format is based on [Keep a > Changelog](https://keepachangelog.com/en/1.0.0/) > > ## [unstable > UNRELEASED](https://xenbits.xen.

Re: [PATCH 12/13] xenpm: Add set-cpufreq-hwp subcommand

On 03.05.2021 21:28, Jason Andryuk wrote: > @@ -1309,6 +1328,226 @@ void disable_turbo_mode(int argc, char *argv[]) > errno, strerror(errno)); > } > > +/* > + * Parse activity_window:NNN{us,ms,s} and validate range. > + * > + * Activity window is a 7bit mantissa (0-127) with a 3

  1   2   >