[PATCH v3 1/2] hw/xen: detect when running inside stubdomain

Introduce global xen_is_stubdomain variable when qemu is running inside a stubdomain instead of dom0. This will be relevant for subsequent patches, as few things like accessing PCI config space need to be done differently. Signed-off-by: Marek Marczykowski-Górecki --- Changes in v3: - move to

[PATCH v3 2/2] xen: fix stubdom PCI addr

When running in a stubdomain, the config space access via sysfs needs to use BDF as seen inside stubdomain (connected via xen-pcifront), which is different from the real BDF. For other purposes (hypercall parameters etc), the real BDF needs to be used. Get the in-stubdomain BDF by looking up

Re: [PATCH v3 1/2] IOMMU: store name for extra reserved device memory

On Wed, Mar 27, 2024 at 03:53:10AM +0100, Marek Marczykowski-Górecki wrote: > It will be useful for error reporting in a subsequent patch. > > Signed-off-by: Marek Marczykowski-Górecki > Acked-by: Jan Beulich This one is already applied, sorry for re-send. > --- > New in v2 > --- >

[PATCH v3 1/2] IOMMU: store name for extra reserved device memory

It will be useful for error reporting in a subsequent patch. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Jan Beulich --- New in v2 --- xen/drivers/char/xhci-dbc.c | 3 ++- xen/drivers/passthrough/iommu.c | 5 - xen/include/xen/iommu.h | 3 ++- 3 files changed, 8

[PATCH v3 2/2] drivers/char: mark extra reserved device memory in memory map

The IOMMU driver checks if RMRR/IVMD are marked as reserved in memory map. This should be true for addresses coming from the firmware, but when extra pages used by Xen itself are included in the mapping, those are taken from usable RAM used. Mark those pages as reserved too. Not marking the pages

Re: [PATCH v2 1/2] IOMMU: store name for extra reserved device memory

On Mon, Mar 18, 2024 at 04:52:42PM +0100, Roger Pau Monné wrote: > On Mon, Mar 18, 2024 at 02:40:21PM +0100, Jan Beulich wrote: > > On 12.03.2024 17:25, Marek Marczykowski-Górecki wrote: > > > It will be useful for error reporting in a subsequent patch. > > > > > > Signed-off-by: Marek

Re: [PATCH v2 2/2] drivers/char: mark extra reserved device memory in memory map

On Mon, Mar 18, 2024 at 02:48:09PM +0100, Jan Beulich wrote: > On 12.03.2024 17:25, Marek Marczykowski-Górecki wrote: > > The IOMMU driver checks if RMRR/IVMD are marked as reserved in memory > > map. This should be true for addresses coming from the firmware, but > > when extra pages used by Xen

Re: [PATCH v2 1/2] hw/xen: detect when running inside stubdomain

On Tue, Mar 26, 2024 at 05:06:50PM +, Anthony PERARD wrote: > On Tue, Mar 05, 2024 at 08:12:29PM +0100, Marek Marczykowski-Górecki wrote: > > diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c > > index 124dd5f3d6..6bd4e6eb2f 100644 > > --- a/hw/xen/xen-legacy-backend.c > >

Re: [PATCH] x86/vcpu: relax VCPUOP_initialise restriction for non-PV vCPUs

Hi Andrew, On 20/03/2024 14:39, Andrew Cooper wrote: On 20/03/2024 2:26 pm, Roger Pau Monné wrote: On Wed, Mar 20, 2024 at 02:06:27PM +, Andrew Cooper wrote: On 20/03/2024 1:57 pm, Roger Pau Monne wrote: There's no reason to force HVM guests to have a valid vcpu_info area when

Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags macro

Hi Carlo & Jan, On 26/03/2024 17:04, Jan Beulich wrote: No, we need to get to the root of the issue. Since osstest has hit it quite easily as it seems, I'm somewhat surprised you didn't hit it in your testing. In any event, as per my earlier reply, my present guess is that your change has

[PATCH v5] RFC: x86/pvh: Make Xen PVH entrypoint PIC for x86-64

The Xen PVH entrypoint is 32bit non-PIC code running at a default load address of 0x100 (16MB) (CONFIG_PHYSICAL_START). Xen loads the kernel at that physical address inside the PVH container. When running a PVH Dom0, the system reserved addresses are mapped 1-1 into the PVH container. There

[PATCH v5 5/6] xen/elfnote: Specify ELF Notes are x86-specific

The Xen ELF Notes are only used with x86. libelf's elf_xen_note_check() exits early for ARM binaries with "ELF: Not bothering with notes on ARM". Add a comment to the top of elfnote.h specifying that Notes are only used with x86 binaries. This is to avoid adding disclaimers for individual

[PATCH v5 6/6] x86/PVH: Support relocatable dom0 kernels

Xen tries to load a PVH dom0 kernel at the fixed guest physical address from the elf headers. For Linux, this defaults to 0x100 (16MB), but it can be configured. Unfortunately there exist firmwares that have reserved regions at this address, so Xen fails to load the dom0 kernel since it's

[PATCH v5 1/6] Revert "xen/x86: bzImage parse kernel_alignment"

A new ELF note will specify the alignment for a relocatable PVH kernel. ELF notes are suitable for vmlinux and other ELF files, so this Linux-specific bzImage parsing in unnecessary. This reverts commit c44cac229067faeec8f49247d1cf281723ac2d40. Signed-off-by: Jason Andryuk ---

[PATCH v5 4/6] libelf: Expand ELF note printing

The XEN_ELFNOTE_L1_MFN_VALID is an array of pairs of values, but it is printed as: (XEN) ELF: note: L1_MFN_VALID = 0 This is a limitation of only printing either string or numeric values. Switch from the boolean to an enum which allows more flexibility in printing the values. Introduce

[PATCH v5 2/6] tools/init-xenstore-domain: Replace variable MB() usage

The local MB() & GB() macros will be replaced with a common implementation, but those only work with constant values. Introduce a static inline mb_to_bytes() in place of the MB() macro to convert the variable values. Signed-off-by: Jason Andryuk --- v4: New ---

[PATCH v5 3/6] tools: Move MB/GB() to common-macros.h

Consolidate to a single set of common macros for tools. MB() will gain another use in libelf, so this movement makes it available. Requested-by: Jan Beulich Signed-off-by: Jason Andryuk Reviewed-by: Jan Beulich --- v4: New v5: Add Jan's R-b & Req-b --- tools/firmware/hvmloader/util.h

[PATCH v5 0/6] x86/pvh: Support relocating dom0 kernel

Xen tries to load a PVH dom0 kernel at the fixed guest physical address from the elf headers. For Linux, this defaults to 0x100 (16MB), but it can be configured. Unfortunately there exist firmwares that have reserved regions at this address, so Xen fails to load the dom0 kernel since it's

Re: [PATCH v6 10/20] xen/riscv: introduce atomic.h

On Tue, 2024-03-26 at 20:02 +0100, Oleksii wrote: > On Mon, 2024-03-25 at 09:18 +0100, Jan Beulich wrote: > > On 22.03.2024 13:25, Oleksii wrote: > > > On Thu, 2024-03-21 at 14:03 +0100, Jan Beulich wrote: > > > > On 15.03.2024 19:06, Oleksii Kurochko wrote: > > > > > + */ > > > > > +static

Re: [PATCH v6 10/20] xen/riscv: introduce atomic.h

On Mon, 2024-03-25 at 09:18 +0100, Jan Beulich wrote: > On 22.03.2024 13:25, Oleksii wrote: > > On Thu, 2024-03-21 at 14:03 +0100, Jan Beulich wrote: > > > On 15.03.2024 19:06, Oleksii Kurochko wrote: > > > > + */ > > > > +static always_inline void read_atomic_size(const volatile void > > > > *p,

Re: [PATCH v2 2/2] xen: fix stubdom PCI addr

First things first, could you fix the coding style? Run something like `./scripts/checkpatch.pl @^..` or `./scripts/checkpatch.pl master..`. Patchew might have run that for you if the patch series had a cover letter. On Tue, Mar 05, 2024 at 08:12:30PM +0100, Marek Marczykowski-Górecki wrote: >

Re: [PATCH v2 1/2] hw/xen: detect when running inside stubdomain

On Tue, Mar 05, 2024 at 08:12:29PM +0100, Marek Marczykowski-Górecki wrote: > diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c > index 124dd5f3d6..6bd4e6eb2f 100644 > --- a/hw/xen/xen-legacy-backend.c > +++ b/hw/xen/xen-legacy-backend.c > @@ -603,6 +603,20 @@ static void

Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags macro

On 26.03.2024 17:39, Carlo Nonato wrote: > On Mon, Mar 25, 2024 at 8:19 AM Jan Beulich wrote: >> On 22.03.2024 16:07, Carlo Nonato wrote: >>> On Thu, Mar 21, 2024 at 5:23 PM Jan Beulich wrote: On 21.03.2024 17:10, Julien Grall wrote: > On 21/03/2024 16:07, Julien Grall wrote: >> On

Re: [PATCH 6/6] xen/x86: Add topology generator

On 09.01.2024 16:38, Alejandro Vallejo wrote: > --- a/tools/include/xenguest.h > +++ b/tools/include/xenguest.h > @@ -843,5 +843,20 @@ enum xc_static_cpu_featuremask { > XC_FEATUREMASK_HVM_HAP_DEF, > }; > const uint32_t *xc_get_static_cpu_featuremask(enum > xc_static_cpu_featuremask); > +

Re: [XEN PATCH] tools: add x2APIC entries in MADT based on APIC ID

On Mon, Mar 25, 2024 at 02:30:35PM +, Alejandro Vallejo wrote: > Hi, > > On 14/03/2024 13:50, Jan Beulich wrote: > > On 13.03.2024 16:35, Matthew Barnes wrote: > >> libacpi is a tool that is used by libxl (for PVH guests) and hvmloader > >> (for HVM guests) to construct ACPI tables for

Re: [PATCH 5/6] xen/x86: Derive topologically correct x2APIC IDs from the policy

On 09.01.2024 16:38, Alejandro Vallejo wrote: > --- a/xen/lib/x86/policy.c > +++ b/xen/lib/x86/policy.c > @@ -2,15 +2,78 @@ > > #include > > -uint32_t x86_x2apic_id_from_vcpu_id(const struct cpu_policy *p, uint32_t > vcpu_id) > +static uint32_t parts_per_higher_scoped_level(const struct

Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags macro

Hi Jan, On Mon, Mar 25, 2024 at 8:19 AM Jan Beulich wrote: > > On 22.03.2024 16:07, Carlo Nonato wrote: > > Hi guys, > > > > On Thu, Mar 21, 2024 at 5:23 PM Jan Beulich wrote: > >> > >> On 21.03.2024 17:10, Julien Grall wrote: > >>> On 21/03/2024 16:07, Julien Grall wrote: > On 15/03/2024

Re: [XEN PATCH] tools: add x2APIC entries in MADT based on APIC ID

On Tue, Mar 26, 2024 at 05:15:46PM +0100, Jan Beulich wrote: > On 26.03.2024 16:57, Matthew Barnes wrote: > >>> This patch scans each APIC ID before constructing the MADT, and uses the > >>> x2APIC entry for each vCPU whose APIC ID exceeds the size limit imposed > >>> by regular APIC entries. > >>

Re: [XEN PATCH] tools: add x2APIC entries in MADT based on APIC ID

On 26.03.2024 16:57, Matthew Barnes wrote: >>> This patch scans each APIC ID before constructing the MADT, and uses the >>> x2APIC entry for each vCPU whose APIC ID exceeds the size limit imposed >>> by regular APIC entries. >> >> It is my understanding that if you use any x2APIC entry, every CPU

Re: [XEN PATCH 09/11] x86/msi: address violation of MISRA C Rule 20.7 and coding style

+#define msi_disable(control) (control) &= ~PCI_MSI_FLAGS_ENABLE Doesn't this need an outer pair of parentheses, too? Not necessarily. And use of msi_disable() in another expression would then likely not do what's expected? Actually I just noticed that some of these macros are

Re: [XEN PATCH] tools: add x2APIC entries in MADT based on APIC ID

> > This patch scans each APIC ID before constructing the MADT, and uses the > > x2APIC entry for each vCPU whose APIC ID exceeds the size limit imposed > > by regular APIC entries. > > It is my understanding that if you use any x2APIC entry, every CPU needs > to have one. In the ACPI 6.4

Re: [XEN PATCH 07/11] xen/page_alloc: address violations of MISRA C Rule 20.7

On 2024-03-26 16:35, Jan Beulich wrote: On 26.03.2024 16:27, Nicola Vetrini wrote: On 2024-03-25 10:27, Jan Beulich wrote: On 22.03.2024 17:01, Nicola Vetrini wrote: --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -150,7 +150,7 @@ #include #else #define

Re: [PATCH v4 5/5] x86/PVH: Support relocatable dom0 kernels

On 2024-03-26 09:40, Jan Beulich wrote: On 26.03.2024 14:24, Jason Andryuk wrote: On 2024-03-26 03:50, Jan Beulich wrote: On 25.03.2024 21:45, Jason Andryuk wrote: @@ -227,6 +239,27 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf, +} +if ( descsz >= 8 ) +

Re: [XEN PATCH 09/11] x86/msi: address violation of MISRA C Rule 20.7 and coding style

On 2024-03-26 16:13, Jan Beulich wrote: On 26.03.2024 15:30, Nicola Vetrini wrote: On 2024-03-26 11:05, Jan Beulich wrote: On 22.03.2024 17:01, Nicola Vetrini wrote: MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses".

Re: [XEN PATCH 07/11] xen/page_alloc: address violations of MISRA C Rule 20.7

On 26.03.2024 16:27, Nicola Vetrini wrote: > On 2024-03-25 10:27, Jan Beulich wrote: >> On 22.03.2024 17:01, Nicola Vetrini wrote: >>> --- a/xen/common/page_alloc.c >>> +++ b/xen/common/page_alloc.c >>> @@ -150,7 +150,7 @@ >>> #include >>> #else >>> #define p2m_pod_offline_or_broken_hit(pg) 0

Re: [XEN PATCH 07/11] xen/page_alloc: address violations of MISRA C Rule 20.7

Hi Jan, sorry, forgot to reply. On 2024-03-25 10:27, Jan Beulich wrote: On 22.03.2024 17:01, Nicola Vetrini wrote: --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -150,7 +150,7 @@ #include #else #define p2m_pod_offline_or_broken_hit(pg) 0 Seeing this in context: Does

Re: [XEN PATCH 09/11] x86/msi: address violation of MISRA C Rule 20.7 and coding style

On 26.03.2024 15:30, Nicola Vetrini wrote: > On 2024-03-26 11:05, Jan Beulich wrote: >> On 22.03.2024 17:01, Nicola Vetrini wrote: >>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion >>> of macro parameters shall be enclosed in parentheses". Therefore, some >>> macro

Re: [XEN PATCH 11/11] x86/public: hvm: address violations of MISRA C Rule 20.7

On 2024-03-26 11:15, Jan Beulich wrote: On 22.03.2024 17:02, Nicola Vetrini wrote: MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses". Therefore, some macro definitions should gain additional parentheses to ensure that all

Re: [XEN PATCH 10/11] x86/hvm: address violations of Rule 20.7

On 2024-03-26 11:13, Jan Beulich wrote: On 22.03.2024 17:01, Nicola Vetrini wrote: MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses". Therefore, some macro definitions should gain additional parentheses to ensure that all

Re: [XEN PATCH 09/11] x86/msi: address violation of MISRA C Rule 20.7 and coding style

On 2024-03-26 11:05, Jan Beulich wrote: On 22.03.2024 17:01, Nicola Vetrini wrote: MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses". Therefore, some macro definitions should gain additional parentheses to ensure that all

Re: [PATCH 11/11] xen/arm: List static shared memory regions as /memory nodes

> On 25 Mar 2024, at 08:58, Michal Orzel wrote: > > Hi Luca, > Hi Michal, > On 12/03/2024 14:03, Luca Fancellu wrote: >> >> >> Currently Xen is not exporting the static shared memory regions >> to the device tree as /memory node, this commit is fixing this >> issue. > Looking at the

Re: [PATCH v4 5/5] x86/PVH: Support relocatable dom0 kernels

On 26.03.2024 14:24, Jason Andryuk wrote: > On 2024-03-26 03:50, Jan Beulich wrote: >> On 25.03.2024 21:45, Jason Andryuk wrote: >>> @@ -227,6 +239,27 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary >>> *elf, >>> case XEN_ELFNOTE_PHYS32_ENTRY: >>> parms->phys_entry = val;

Re: [PATCH v4 5/5] x86/PVH: Support relocatable dom0 kernels

On 26.03.2024 14:24, Jason Andryuk wrote: > On 2024-03-26 03:50, Jan Beulich wrote: >> On 25.03.2024 21:45, Jason Andryuk wrote: >>> + * - a minimum address for the start of the image (default 0) >>> + * - a required start alignment (default 0x20) >>> + * >>> + * This note is only valid for

Re: [PATCH v4 5/5] x86/PVH: Support relocatable dom0 kernels

On 2024-03-26 03:50, Jan Beulich wrote: On 25.03.2024 21:45, Jason Andryuk wrote: +/* Find an e820 RAM region that fits the kernel at a suitable alignment. */ +static paddr_t __init find_kernel_memory( +const struct domain *d, struct elf_binary *elf, +const struct elf_dom_parms *parms)

Re: [PATCH] x86/spec-ctrl: Support for SRSO_US_NO and SRSO_MSR_FIX

On 26.03.2024 12:33, Andrew Cooper wrote: > On 26/03/2024 9:13 am, Jan Beulich wrote: >> On 25.03.2024 19:18, Andrew Cooper wrote: >>> + /* Avoid reading BP_CFG if we don't intend to change anything. */ >>> + if (!new) >>> return; >>> >>> rdmsrl(MSR_AMD64_BP_CFG, val); >>>

Re: [OSSTEST PATCH 33/36] make-flight: Keep using buster for L2 guest in nested tests

On Wed, Mar 20, 2024 at 06:24:18PM +0100, Roger Pau Monné wrote: > On Mon, Mar 18, 2024 at 04:55:42PM +, Anthony PERARD wrote: > > When starting the installation of the L2 guest, L0 kills L1. Switching > > the L2 guest back to Debian Buster works fine, so do that to prevent > > regression in

Re: [OSSTEST PATCH 34/36] Temporally switch "qemu-mainline" branch to Bookworm

On Wed, Mar 20, 2024 at 06:25:35PM +0100, Roger Pau Monné wrote: > On Mon, Mar 18, 2024 at 04:55:43PM +, Anthony PERARD wrote: > > QEMU doesn't build on buster anymore. > > > > This should be remove once bookworm is the default suite. > > Is this change required anymore, patch 35 makes

Re: [OSSTEST PATCH 10/36] preseed_create: Workaround fail grub-install on arndale

On Wed, Mar 20, 2024 at 05:38:17PM +0100, Roger Pau Monné wrote: > On Mon, Mar 18, 2024 at 04:55:19PM +, Anthony PERARD wrote: > > grub-installer on arndale-* machine fails with Debian Bookworm. It > > tries to install "grub-pc" which doesn't exist. Skip installation. > > > > Somehow,

Re: [PATCH] x86/spec-ctrl: Support for SRSO_US_NO and SRSO_MSR_FIX

On 26/03/2024 9:13 am, Jan Beulich wrote: > On 25.03.2024 19:18, Andrew Cooper wrote: >> --- a/docs/misc/xen-command-line.pandoc >> +++ b/docs/misc/xen-command-line.pandoc >> @@ -2377,7 +2377,8 @@ By default SSBD will be mitigated at runtime (i.e >> `ssbd=runtime`). >> >

[xen-unstable test] 185162: tolerable FAIL

flight 185162 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/185162/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail pass in 185158 Tests which did not

Re: NULL pointer dereference in xenbus_thread->...

Hi Marek, +Juergen for visibility When sending a bug report, I would suggest to CC relevant people as otherwise it can get lost (not may people monitors Xen devel if they are not CCed). Cheers, On 25/03/2024 16:17, Marek Marczykowski-Górecki wrote: On Sun, Oct 22, 2023 at 04:14:30PM

Join the conversation on Matrix

Hello Xen Community, We welcome all new and existing members to join the conversation. Other than mailing lists, most of us are active on Matrix. Join us below: *XenProject* For general queries and updates about the software. This channel is mainly

Re: [XEN PATCH 08/11] x86/altcall: address violations of MISRA C Rule 20.7

On 2024-03-25 15:58, Jan Beulich wrote: On 25.03.2024 15:47, Nicola Vetrini wrote: On 2024-03-25 10:38, Jan Beulich wrote: On 22.03.2024 17:01, Nicola Vetrini wrote: MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses".

Re: [XEN PATCH 11/11] x86/public: hvm: address violations of MISRA C Rule 20.7

On 22.03.2024 17:02, Nicola Vetrini wrote: > MISRA C Rule 20.7 states: "Expressions resulting from the expansion > of macro parameters shall be enclosed in parentheses". Therefore, some > macro definitions should gain additional parentheses to ensure that all > current and future users will be

Re: [XEN PATCH 10/11] x86/hvm: address violations of Rule 20.7

On 22.03.2024 17:01, Nicola Vetrini wrote: > MISRA C Rule 20.7 states: "Expressions resulting from the expansion > of macro parameters shall be enclosed in parentheses". Therefore, some > macro definitions should gain additional parentheses to ensure that all > current and future users will be

Re: [XEN PATCH 09/11] x86/msi: address violation of MISRA C Rule 20.7 and coding style

On 22.03.2024 17:01, Nicola Vetrini wrote: > MISRA C Rule 20.7 states: "Expressions resulting from the expansion > of macro parameters shall be enclosed in parentheses". Therefore, some > macro definitions should gain additional parentheses to ensure that all > current and future users will be

Re: [PATCH] x86/spec-ctrl: Support for SRSO_US_NO and SRSO_MSR_FIX

On 25.03.2024 19:18, Andrew Cooper wrote: > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -2377,7 +2377,8 @@ By default SSBD will be mitigated at runtime (i.e > `ssbd=runtime`). > > {msr-sc,rsb,verw,ibpb-entry}=|{pv,hvm}=, > >

Re: [PATCH v6 10/11] virtio-gpu: Initialize Venus

Le 23/02/2024 à 10:15, Huang Rui a écrit : On Tue, Jan 02, 2024 at 09:33:11PM +0800, Marc-André Lureau wrote: Hi On Tue, Dec 19, 2023 at 11:55 AM Huang Rui wrote: From: Antonio Caggiano Request Venus when initializing VirGL. Signed-off-by: Antonio Caggiano Signed-off-by: Huang Rui

Re: [PATCH] tools/misc: fix xenwatchdogd invocation

On 26.03.2024 06:15, zithro / Cyril Rébert wrote: > --- a/tools/misc/xenwatchdogd.c > +++ b/tools/misc/xenwatchdogd.c > @@ -8,26 +8,34 @@ > #include > #include > #include > +#include > #include > > +#define _GNU_SOURCE This wants defining first thing in a file (or even on the compiler

Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue

Hi John, > On 25 Mar 2024, at 13:18, John Ernberg wrote: > > Hi Bertrand, > > On 3/21/24 17:15, Bertrand Marquis wrote: >> Hi John, >> >>> On 21 Mar 2024, at 17:05, John Ernberg wrote: >>> >>> Hi Bertrand, >>> >>> On 3/21/24 08:41, Bertrand Marquis wrote: Hi, > On 20 Mar

Re: [PATCH v4 4/5] libelf: Expand ELF note printing

On 25.03.2024 21:45, Jason Andryuk wrote: > @@ -145,13 +150,18 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary > *elf, > elf_msg(elf, "ELF: note: %s = \"%s\"\n", note_desc[type].name, str); > parms->elf_notes[type].type = XEN_ENT_STR; >

Re: [PATCH v4 5/5] x86/PVH: Support relocatable dom0 kernels

On 25.03.2024 21:45, Jason Andryuk wrote: > +/* Find an e820 RAM region that fits the kernel at a suitable alignment. */ > +static paddr_t __init find_kernel_memory( > +const struct domain *d, struct elf_binary *elf, > +const struct elf_dom_parms *parms) > +{ > +paddr_t kernel_size =

Re: [PATCH v4 3/5] tools: Move MB/GB() to common-macros.h

On 25.03.2024 21:45, Jason Andryuk wrote: > Consolidate to a single set of common macros for tools. > > MB() will gain another use in libelf, so this movement makes it > available. > > Signed-off-by: Jason Andryuk Reviewed-by: Jan Beulich (and perhaps also Requested-by: or some such)

Re: [PATCH 1/6] xen/x86: Add initial x2APIC ID to the per-vLAPIC save area

On 25.03.2024 19:00, Alejandro Vallejo wrote: > On 25/03/2024 16:45, Jan Beulich wrote: >> On 09.01.2024 16:38, Alejandro Vallejo wrote: >>> @@ -1514,6 +1530,13 @@ static void lapic_load_fixup(struct vlapic *vlapic) >>> const struct vcpu *v = vlapic_vcpu(vlapic); >>> uint32_t good_ldr =

[linux-linus test] 185160: tolerable FAIL - PUSHED

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