flight 161443 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161443/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
flight 161437 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161437/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 161447 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161447/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen bea65a212c0581520203b6ad0d07615693f42f73
baseline version:
xen aaa3
flight 161439 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161439/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-examine4 memdisk-try-append fail in 161421 pass in 161439
test-amd64-amd64-xl-qemut-debian
Hi Juergen,
On 21/04/2021 08:39, Juergen Gross wrote:
On 20.04.21 15:49, Julien Grall wrote:
From: Julien Grall
A prototype for dump_conn() has been present for quite a long time
but there are no implementation. Even, AFAICT in the patch that
introduced it. So drop it.
Signed-off-by: Julien
Hi Juergen,
On 21/04/2021 16:07, Juergen Gross wrote:
On 21.04.21 16:02, Julien Grall wrote:
From: Julien Grall
The command line option -M/--path-max was meant to be added by
commit 924bf8c793cb "tools/xenstore: rework path length check" but this
wasn't wired through properly.
Fix it by addi
Hi Jan,
On 07/04/2021 10:25, Jan Beulich wrote:
On 06.04.2021 21:22, Julien Grall wrote:
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -457,6 +457,12 @@ static long total_avail_pages;
static DEFINE_SPINLOCK(heap_lock);
static long outstanding_claims; /* total outstanding cl
Hi Stefano,
On 30/11/2020 22:05, Stefano Stabellini wrote:
On Sat, 28 Nov 2020, Julien Grall wrote:
If you take the ``if`` alone, yes they are alignment check. But if you take
the overall code, then it will just compute which mapping size can be used.
However, what I am disputing here is "rely
flight 161449 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161449/
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 161442 xen-4.12-testing real [real]
flight 161452 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161442/
http://logs.test-lab.xenproject.org/osstest/logs/161452/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
From: Julien Grall
The array level_orders and level_masks can be replaced with the
recently introduced macros LEVEL_ORDER and LEVEL_MASK.
Signed-off-by: Julien Grall
---
Changes in v2:
- New patch
---
xen/arch/arm/p2m.c | 16 +---
1 file changed, 5 insertions(+), 11 de
From: Julien Grall
Hi all,
This series was originally sent as "xen/arm: mm: Add limited support
for superpages" [1] and finally has grown enough to remove most of
the open-coding mappings in the boot code.
This will help to:
1) Get better compliance with the Arm memory model
2) Pave the
From: Julien Grall
At the moment, xen_pt_update_entry() only supports mapping at level 3
(i.e 4KB mapping). While this is fine for most of the runtime helper,
the boot code will require to use superpage mapping.
We don't want to allow superpage mapping by default as some of the
callers may expec
From: Julien Grall
Currently, the function xen_pt_update() will flush the TLBs even when
the mappings are inserted. This is a bit wasteful because we don't
allow mapping replacement. Even if we were, the flush would need to
happen earlier because mapping replacement should use Break-Before-Make
w
From: Julien Grall
Commit 05031fa87357 "xen/arm: guest_walk: Only generate necessary
offsets/masks" introduced LPAE_ENTRIES_MASK_GS. In a follow-up patch,
we will use it for to define LPAE_ENTRY_MASK.
This will lead to inconsistent naming. As LPAE_ENTRY_MASK is used in
many places, it is better
From: Julien Grall
Currently, Xen PT helpers are only working with 4KB page granularity
and open-code the generic helpers. To allow more flexibility, we can
re-use the generic helpers and pass Xen's page granularity
(PAGE_SHIFT).
As Xen PT helpers are used in both C and assembly, we need to move
From: Julien Grall
Now that map_pages_to_xen() has been extended to support 2MB mappings,
we can replace the create_mappings() calls by map_pages_to_xen() calls.
The mapping can also be marked read-only has Xen as no business to
modify the host Device Tree.
Signed-off-by: Julien Grall
Signed-o
From: Julien Grall
Now that xen_pt_update_entry() is able to deal with different mapping
size, we can replace the open-coding of the page-tables update by a call
to modify_xen_mappings().
As the function is not meant to fail, a BUG_ON() is added to check the
return.
Signed-off-by: Julien Grall
From: Julien Grall
Only the first 2GB of the virtual address space is shared between all
the page-tables on Arm32.
There is a long outstanding TODO in xen_pt_update() stating that the
function is can only work with shared mapping. Nobody has ever called
the function with private mapping, however
From: Julien Grall
Now that map_pages_to_xen() has been extended to support 2MB mappings,
we can replace the create_mappings() call by map_pages_to_xen() call.
Signed-off-by: Julien Grall
---
Changes in v2:
- New patch
TODOs:
- add support for contiguous mapping
---
x
On 21/04/2021 10:32, Henry Wang wrote:
Hi Julien,
Hi Henry,
-Original Message-
From: Julien Grall
Sent: Wednesday, April 21, 2021 5:04 PM
To: Henry Wang ; sstabell...@kernel.org; xen-
de...@lists.xenproject.org
Cc: Wei Chen ; Penny Zheng
; Bertrand Marquis
Subject: Re: Discussion
From: Julien Grall
A few issues have been reported with setup_xenheap_mappings() over the
last couple of years. The main ones are:
- It will break on platform supporting more than 512GB of RAM
because the memory allocated by the boot allocator is not yet
mapped.
- Aligning all
From: Julien Grall
During early boot, it is not possible to use xen_{,un}map_table()
if the page tables are not residing the Xen binary.
This is a blocker to switch some of the helpers to use xen_pt_update()
as we may need to allocate extra page tables and access them before
the domheap has been
From: Wei Liu
The basic idea is like Persistent Kernel Map (PKMAP) in Linux. We
pre-populate all the relevant page tables before the system is fully
set up.
We will need it on Arm in order to rework the arm64 version of
xenheap_setup_mappings() as we may need to use pages allocated from
the boot
From: Julien Grall
xen_{un,}map_table() already uses the helper to map/unmap pages
on-demand (note this is currently a NOP on arm64). So switching to
domheap don't have any disavantage.
But this as the benefit:
- to keep the page tables unmapped if an arch decided to do so
- reduce xenhe
From: Julien Grall
At the moment, page-table can only be allocated from domheap. This means
it is not possible to create mapping in the page-tables via
map_pages_to_xen() if page-table needs to be allocated.
In order to avoid open-coding page-tables update in early boot, we need
to be able to al
From: Julien Grall
Now that map_pages_to_xen() has been extended to support 2MB mappings,
we can replace the create_mappings() call by map_pages_to_xen() call.
This has the advantage to remove the different between 32-bit and 64-bit
code.
Lastly remove create_mappings() as there is no more call
flight 161444 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161444/
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
flight 161446 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161446/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
Kernel on Xen is loaded via fw_cfg. Previously it used non-DMA version,
which loaded the kernel (and initramfs) byte by byte. Change this
to DMA, to load in bigger chunks.
This change alone reduces load time of a (big) kernel+initramfs from
~10s down to below 1s.
This change was suggested initiall
flight 161451 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161451/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 161439
test-armhf-armhf-libvirt 16 save
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.13-rc1-tag
xen: branch for v5.13-rc1
It contains:
- A patch for removing some PV ACPI cpu/memory hotplug code which has
been broken for a long time.
- A patch supporting direct
32 matches
Mail list logo
