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,
>
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
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
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
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
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
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
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:
> ---
v5 here: https://lore.kernel.org/patchwork/cover/1416899/ to rebase
onto Christoph's swiotlb cleanups.
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
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
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
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
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 @@
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.
> >
>
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
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
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
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
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
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,
> >
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 -
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
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
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
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
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
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
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
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
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):
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
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
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
> 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:
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
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;
>>>
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
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
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.
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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 /
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.
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
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:
> ---
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
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_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
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
On 22.04.2021 16:56, Roger Pau Monné wrote:
> 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
On 22.04.2021 17:53, Roger Pau Monné wrote:
> On Thu, Apr 22, 2021 at 05:46:28PM +0200, Jan Beulich wrote:
>> On 22.04.2021 16:56, Roger Pau Monné wrote:
>>> 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
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
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 /
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
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
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
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
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
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
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 {
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;
>> +
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
On Thu, 22 Apr 2021, Juergen Gross wrote:
> 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
On 22.04.21 17:23, Jan Beulich wrote:
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
On 22.04.21 17:42, Jan Beulich wrote:
On 22.04.2021 17:28, Juergen Gross wrote:
On 22.04.21 17:23, Jan Beulich wrote:
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
On 22/04/2021 16:42, Jan Beulich wrote:
> On 22.04.2021 17:28, Juergen Gross wrote:
>> On 22.04.21 17:23, Jan Beulich wrote:
>>> 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
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
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;
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
+++
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
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
+++
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
+++
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.
---
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.
---
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
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
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 !=
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
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):
On 22.04.21 17:26, Stefano Stabellini wrote:
On Thu, 22 Apr 2021, Juergen Gross wrote:
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
On 22.04.2021 17:28, Juergen Gross wrote:
> On 22.04.21 17:23, Jan Beulich wrote:
>> 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
>
On Thu, Apr 22, 2021 at 05:46:28PM +0200, Jan Beulich wrote:
> On 22.04.2021 16:56, Roger Pau Monné wrote:
> > 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
1 - 100 of 130 matches
Mail list logo