flight 188315 xen-unstable real [real]
flight 188316 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/188315/
http://logs.test-lab.xenproject.org/osstest/logs/188316/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
Given that soffs is the offset into the 2M superpage,
start = (src - soffs) >> PAGE_SIFT
is a complicated expression for the frame address of the containing superpage.
Except, start is converted straight back to a byte address to use, so the
shifting is unnecessary too.
The only done with the
move_memory() is very complicated, and buggy. In order to fix the latter, we
have to address the former.
Given prior cleanup, bootstrap_map() is now implemented in terms of
bootstrap_map_addr(), meaining that it is counterproductive to plumb the
mapping through module_t.
Delete mod, and introduc
While both src and dst are similar, src is mapped only accounting for src's
size, while dst is mapped based on the minimum of both. This means that in
some cases, an overly large mapping is requested for src.
Rework the sz calcuation to be symmetric, and leave an explanation of how
logic works.
Strip module_t out of move_memory() and simplify the logic.
This is to allow yet-more cleanup with the hyperlaunch series. See patch 1
for most of the discussion.
https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1507885241
Andrew Cooper (3):
x86/boot: Convert move_memory() to use
On Wed, Oct 16, 2024 at 02:28:27PM +0800, Jiqian Chen wrote:
> --- a/hw/xen/xen_pt.h
> +++ b/hw/xen/xen_pt.h
> @@ -36,6 +36,7 @@ void xen_pt_log(const PCIDevice *d, const char *f, ...)
> G_GNUC_PRINTF(2, 3);
> # define XEN_PT_LOG_CONFIG(d, addr, val, len)
> #endif
>
> +#define DOMID_RUN_QEMU
flight 188318 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188318/
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 10/22/24 18:39, Andrew Cooper wrote:
move_memory() is very complicated, and buggy. In order to fix the latter, we
have to address the former.
Given prior cleanup, bootstrap_map() is now implemented in terms of
bootstrap_map_addr(), meaining that it is counterproductive to plumb the
mapping t
On 10/22/24 18:39, Andrew Cooper wrote:
Given that soffs is the offset into the 2M superpage,
start = (src - soffs) >> PAGE_SIFT
is a complicated expression for the frame address of the containing superpage.
Except, start is converted straight back to a byte address to use, so the
shifting i
On 10/22/24 18:39, Andrew Cooper wrote:
While both src and dst are similar, src is mapped only accounting for src's
size, while dst is mapped based on the minimum of both. This means that in
some cases, an overly large mapping is requested for src.
Rework the sz calcuation to be symmetric, and
On 21/10/2024 10:55 am, Federico Serafini wrote:
> Add missing break statements to address violations of MISRA C:2012
> Rule 16.3 (An unconditional `break' statement shall terminate
> every switch-clause).
>
> Make explicit unreachability of a program point with
> ASSERT_UNREACHABLE() and add defen
+Julien
On Wed, 16 Oct 2024, Ryan Roberts wrote:
> + Juergen Gross, Stefano Stabellini
>
> This was a rather tricky series to get the recipients correct for and my
> script
> did not realize that "supporter" was a pseudonym for "maintainer" so you were
> missed off the original post. Appologies!
Hi Julien,
> On 22 Oct 2024, at 14:13, Julien Grall wrote:
>
>
>
> On 22/10/2024 10:56, Luca Fancellu wrote:
>>> On 22 Oct 2024, at 10:47, Julien Grall wrote:
>>>
>>> Hi Luca,
>>>
>>> On 22/10/2024 10:41, Luca Fancellu wrote:
> On 21 Oct 2024, at 17:27, Julien Grall wrote:
2) dsb+
Right now, builds of pvshim are non-debug, because of pvshim_defconfig.
However, this means that Gitlab CI testing is less effective than it wants to
be.
Include Rules.mk, and feed the tools-wide debug= setting.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Anthony P
From: Bernhard Kaindl
Some admin tools like 'xl info -n' like to display the total memory
for each NUMA node. The Xen backend[1] of hwloc comes to mind too.
The total amount of RAM on a NUMA node is not needed by Xen internally:
Xen only uses NODE_DATA->node_spanned_pages, but that can be confus
Hi,
The subject was probably meant to have a v3?
On Tue Oct 22, 2024 at 11:10 AM BST, Bernhard Kaindl wrote:
> From: Bernhard Kaindl
>
> Some admin tools like 'xl info -n' like to display the total memory
> for each NUMA node. The Xen backend[1] of hwloc comes to mind too.
>
> The total amount o
Hi Julien,
> On 21 Oct 2024, at 17:27, Julien Grall wrote:
>
>
>
> On 21/10/2024 17:24, Luca Fancellu wrote:
>> Hi Ayan,
> + */
> +FUNC_LOCAL(enable_mpu)
> +mrs x0, SCTLR_EL2
> +bic x0, x0, #SCTLR_ELx_BR /* Disable Background region */
> +orr x0, x0,
Hi Luca,
On 22/10/2024 10:41, Luca Fancellu wrote:
On 21 Oct 2024, at 17:27, Julien Grall wrote:
2) dsb+isb barrier after enabling the MPU, since we are enabling the MPU but
also because we are disabling the background region
TBH, I don't understand this one. Why would disabling the backgro
flight 188317 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188317/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-libvirt-vhd 22 leak-check/check fail in 188315 pass in 188317
test-armhf-armhf-xl-qcow220
On 21/10/2024 11:28 pm, Stefano Stabellini wrote:
> On Mon, 21 Oct 2024, Andrew Cooper wrote:
>> diff --git a/automation/scripts/qubes-x86-64.sh
>> b/automation/scripts/qubes-x86-64.sh
>> index 76fbafac84..95090eb12c 100755
>> --- a/automation/scripts/qubes-x86-64.sh
>> +++ b/automation/scripts/qu
On 21/10/2024 10:53 am, Andrew Cooper wrote:
> On 21/10/2024 1:45 am, Daniel P. Smith wrote:
>> To start transitioning consider_modules() over to struct boot_module, begin
>> with taking the array of struct boot_modules but use the temporary struct
>> element mod.
>>
>> No functional change intende
flight 188319 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188319/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 188317
test-amd64-amd64-xl-qemut-win7-amd64
On Tue, 22 Oct 2024, victorm.l...@amd.com wrote:
> From: Victor Lira
>
> Add x86_64 hardware test that creates a Xen Argo communication
> connection between two PVH domains. In the test, dom0 creates a domU and
> listens for messages sent by the domU through Argo.
>
> To accomplish this, build X
On Tue, 22 Oct 2024, victorm.l...@amd.com wrote:
> From: Stefano Stabellini
Hi Victor, I think this was a mistake, maybe due to the fact that I
created the repository for you. The From field represent the vauthor and
in this case it should be you.
> Create new repository to produce common artif
From: Stefano Stabellini
Create new repository to produce common artifacts for Xen tests
Requested-by: Andrew Cooper
Signed-off-by: Victor Lira
---
Cc: Andrew Cooper
Cc: Marek Marczykowski-Górecki
Cc: Doug Goldstein
Cc: Stefano Stabellini
Cc: xen-devel@lists.xenproject.org
---
.gitlab-ci.
From: Victor Lira
Add x86_64 hardware test that creates a Xen Argo communication
connection between two PVH domains. In the test, dom0 creates a domU and
listens for messages sent by the domU through Argo.
To accomplish this, build Xen with CONFIG_ARGO=y.
Update the xilinx x86_64 test script to
From: Victor Lira
This patch series is a proof of concept that a separate repository can be
used to generate kernel, rootfs, and other commonly used binary artifacts,
and have Xen test jobs load these instead of generating them every run.
The current configuration of Xen CI generates these using
On 22/10/2024 10:56, Luca Fancellu wrote:
On 22 Oct 2024, at 10:47, Julien Grall wrote:
Hi Luca,
On 22/10/2024 10:41, Luca Fancellu wrote:
On 21 Oct 2024, at 17:27, Julien Grall wrote:
2) dsb+isb barrier after enabling the MPU, since we are enabling the MPU but
also because we are di
> On 22 Oct 2024, at 10:47, Julien Grall wrote:
>
> Hi Luca,
>
> On 22/10/2024 10:41, Luca Fancellu wrote:
>>> On 21 Oct 2024, at 17:27, Julien Grall wrote:
>> 2) dsb+isb barrier after enabling the MPU, since we are enabling the MPU but
>> also because we are disabling the background region
multiboot_fill_boot_info() taking the physical address of the multiboot_info
structure leads to a subtle use-after-free on the PVH path, with rather less
subtle fallout.
The pointers used by __start_xen(), mbi and mod, are either:
- MB: Directmap pointers into the trampoline, or
- PVH: Xen poi
On 22/10/2024 12:46 pm, Roger Pau Monne wrote:
> BUG_ON() itself already contains an unlikely() wrapping the bug condition.
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
likely()/unlikely() annotations are notoriously difficult for humans to
reason about,
On 22/10/2024 3:12 pm, Roger Pau Monné wrote:
> On Tue, Oct 22, 2024 at 01:41:14PM +0100, Andrew Cooper wrote:
>> multiboot_fill_boot_info() taking the physical address of the multiboot_info
>> structure leads to a subtle use-after-free on the PVH path, with rather less
>> subtle fallout.
>>
>> The
On Tue, 15 Oct 2024 20:51:12 +0200,
Philipp Stanner wrote:
>
> pci_intx() is a hybrid function which can sometimes be managed through
> devres. To remove this hybrid nature from pci_intx(), it is necessary to
> port users to either an always-managed or a never-managed version.
>
> hda_intel enabl
On Tue, Oct 22, 2024 at 02:25:54PM +0100, Andrew Cooper wrote:
> On 21/10/2024 11:28 pm, Stefano Stabellini wrote:
> > On Mon, 21 Oct 2024, Andrew Cooper wrote:
> >> diff --git a/automation/scripts/qubes-x86-64.sh
> >> b/automation/scripts/qubes-x86-64.sh
> >> index 76fbafac84..95090eb12c 100755
>
On Mon, 21 Oct 2024 at 08:40, Edgar E. Iglesias
wrote:
>
> From: "Edgar E. Iglesias"
>
> The following changes since commit f1dd640896ee2b50cb34328f2568aad324702954:
>
> Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
> (2024-10-18 10:42:56 +0100)
>
> are available in
On Tue, Oct 22, 2024 at 01:41:14PM +0100, Andrew Cooper wrote:
> multiboot_fill_boot_info() taking the physical address of the multiboot_info
> structure leads to a subtle use-after-free on the PVH path, with rather less
> subtle fallout.
>
> The pointers used by __start_xen(), mbi and mod, are ei
BUG_ON() itself already contains an unlikely() wrapping the bug condition.
No functional change.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/pv/mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/pv/mm.c b/xen/arch/x86/pv/mm.c
index 24f0d2e4ff7d..187f5f6a3e
37 matches
Mail list logo
