> On 23 Apr 2021, at 06:40, Juergen Gross wrote:
>
> Commit d3eeb1d77c5d0af ("xen/gntdev: use mmu_interval_notifier_insert")
> introduced an error in gntdev_mmap(): in case the call of
> mmu_interval_notifier_insert_locked() fails the exit path should not
> call mmu_interval_notifier_remove(),
Commit d3eeb1d77c5d0af ("xen/gntdev: use mmu_interval_notifier_insert")
introduced an error in gntdev_mmap(): in case the call of
mmu_interval_notifier_insert_locked() fails the exit path should not
call mmu_interval_notifier_remove(), as this might result in NULL
dereferences.
One reason for fail
On 4/22/21 2:19 AM, Christoph Hellwig wrote:
> 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
I tested
On Mon, Apr 19, 2021 at 11:33:27AM +0200, Juergen Gross wrote:
> Could you try the attached patch?
I've tried and it works, as in - I didn't get the crash in ~20 runs.
Since the issue is quite hard to reproduce, I'm not fully sure it
helped, but sounds plausible. I think you can treat this as Test
On Thu, Apr 22, 2021 at 4:17 PM Claire Chang wrote:
>
> 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 +
> driv
flight 161383 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161383/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 159418
Tests which di
flight 161371 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161371/
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
flight 161392 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161392/
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
flight 161368 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161368/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 161340
test-armhf-armhf-libvirt 16 save
flight 161375 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161375/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 2cf3168661355565e2b80395ef16c5ee3cfc5f55
baseline version:
xtf e24fbec38e66e0df8471ef
flight 161386 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161386/
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
On Wed, 21 Apr 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 21/04/2021 01:38, Stefano Stabellini wrote:
> > On Tue, 20 Apr 2021, Julien Grall wrote:
> > > AFAICT, there is nothing in the implementation of
> > > XEN_DOMCTL_getvcpucontext
> > > that justify the extra barrier (assuming we consider
flight 161364 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161364/
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
Hi Andrew,
On 19/04/2021 15:01, Andrew Cooper wrote:
When compiling at -Og:
domain_build.c: In function 'make_cpus_node':
domain_build.c:926:12: error: 'clock_valid' may be used uninitialized in
this function [-Werror=maybe-uninitialized]
926 | if ( clock_valid )
|
From: Hongyan Xia
Commit 'x86/mm: switch to new APIs in modify_xen_mappings' applied the
hunk of the unmap call to map_pages_to_xen() which was wrong and clearly
should have been at the end of modify_xen_mappings(). Fix.
Fixes: dd68f2e49bea ("x86/mm: switch to new APIs in modify_xen_mappings")
On 22/04/2021 17:35, Hongyan Xia wrote:
> Please see my reply in 03/13. Can you check this diff and see if you
> can still trigger this issue:
>
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 50229e38d384..84e3ccf47e2a 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -5
Hi Hongyan,
On 22/04/2021 17:35, Hongyan Xia wrote:
Please see my reply in 03/13. Can you check this diff and see if you
can still trigger this issue:
I can reproduced the same issue as Andrew. I have applied the patch and
confirm this resolves the problem. Can you send a formal patch?
BTW,
flight 161380 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161380/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 8 xen-bootfail REGR. vs. 161377
test-amd64-a
Please see my reply in 03/13. Can you check this diff and see if you
can still trigger this issue:
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 50229e38d384..84e3ccf47e2a 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5532,7 +5532,6 @@ int map_pages_to_xen(
out:
L3
On 21/04/2021 15:15, Hongyan Xia wrote:
> From: Hongyan Xia
>
> This series rewrites all the remaining functions and finally makes the
> switch from xenheap to domheap for Xen page tables, so that they no
> longer need to rely on the direct map, which is a big step towards
> removing the direct ma
flight 161360 xen-4.12-testing real [real]
flight 161382 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161360/
http://logs.test-lab.xenproject.org/osstest/logs/161382/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
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 0
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 2
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 as
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 pre
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 0
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
> cent
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.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 checks
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 file
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: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
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 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
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
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
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
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
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
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
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
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
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
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 {
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
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
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:
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
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
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
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
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
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
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
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
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-
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
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;
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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,
> >
v5 here: https://lore.kernel.org/patchwork/cover/1416899/ to rebase
onto Christoph's swiotlb cleanups.
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
1 - 100 of 130 matches
Mail list logo
