On Fri, Apr 26, 2024 at 08:41:48AM +0200, Jan Beulich wrote:
> On 24.04.2024 10:19, Roger Pau Monne wrote:
> > @@ -571,6 +575,19 @@ int main(int argc, char *argv[])
> > show_help();
> > return 0;
> > }
> > +
> > +if ( strcmp("--force", argv[1]) )
>
> I guess this
On Wed, Apr 24, 2024 at 10:19:56AM +0200, Roger Pau Monne wrote:
> Livepatch payloads containing symbols that belong to init sections can only
> lead to page faults later on, as by the time the livepatch is loaded init
> sections have already been freed.
>
> Refuse to resolve such symbols and
On Thu, Apr 25, 2024 at 09:26:59AM +0200, Jan Beulich wrote:
> On 25.04.2024 09:10, Roger Pau Monné wrote:
> > On Thu, Apr 25, 2024 at 08:12:09AM +0200, Jan Beulich wrote:
> >> On 24.04.2024 21:18, Daniel P. Smith wrote:
> >>> @@ -1089,6 +1098,9 @@ static int __i
On Thu, Apr 25, 2024 at 08:12:09AM +0200, Jan Beulich wrote:
> On 24.04.2024 21:18, Daniel P. Smith wrote:
> > @@ -1089,6 +1098,9 @@ static int __init pvh_setup_acpi_xsdt(struct domain
> > *d, paddr_t madt_addr,
> > xsdt->header = *table;
> > acpi_os_unmap_memory(table, sizeof(*table));
s RSDT but no
XSDT.
> Fixes: 1d74282c455f ('x86: setup PVHv2 Dom0 ACPI tables')
> Suggested-by: Roger Pau Monné
> Signed-off-by: Stefano Stabellini
> Signed-off-by: Daniel P. Smith
Reviewed-by: Roger Pau Monné
Thanks, Roger.
On Wed, Apr 24, 2024 at 01:41:25PM +0200, Jan Beulich wrote:
> On 24.04.2024 11:34, Roger Pau Monné wrote:
> > On Tue, Apr 23, 2024 at 04:32:32PM +0200, Jan Beulich wrote:
> >> ... thanks to paging_vcpu_init() being part of vCPU creation. Further
> >> if paging is ena
On Wed, Apr 24, 2024 at 01:44:39PM +0200, Jan Beulich wrote:
> On 24.04.2024 12:06, Roger Pau Monné wrote:
> > On Tue, Apr 23, 2024 at 04:33:09PM +0200, Jan Beulich wrote:
> >> As of the commit referenced below the update_paging_modes() hook is per-
> >> domain and henc
g to any (legitimate) mode,
> + * as long as it can be compiled.
Do you need to keep the last sentence? If update_paging_modes is
already set at domain create, the 'Therefore it really does...'
doesn't seem to make much sense anymore, as it's no longer
shadow_vcpu_init() that sets it.
Possibly with that dropped:
Acked-by: Roger Pau Monné
Thanks, Roger.
by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks, Roger.
function execution
after an error is found, I specially dislike that you have to add a
!rc check to the nestedhvm conditional block, and because anything
that we further add to the function would also need a !rc check.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Albeit I do p
On Tue, Apr 23, 2024 at 04:28:59PM +0200, Jan Beulich wrote:
> On 23.04.2024 16:26, Roger Pau Monné wrote:
> > On Tue, Apr 23, 2024 at 03:44:42PM +0200, Jan Beulich wrote:
> >> On 23.04.2024 15:12, Roger Pau Monne wrote:
> >>> Livepatch payloads containing symbols th
t; > and
> > active even before a patch is applied (because hooks might already rely on
> > it),
> > make sure the exception table (if any) only contains fixups for the payload
> > text section.
> >
> > Signed-off-by: Roger Pau Monné
>
> In principle
&g
gt; > resolutions against it.
> >
> > Since __init_begin can alias other symbols (like _erodata for example)
> > allow the force flag to override the check and resolve the symbol anyway.
> >
> > Signed-off-by: Roger Pau Monné
>
> In principle, as promised
On Tue, Apr 23, 2024 at 03:33:36PM +0200, Jan Beulich wrote:
> On 23.04.2024 15:12, Roger Pau Monne wrote:
> > It's incorrect to restrict strncmp to the length of the command line input
> > parameter, as then a user passing a rune like:
> >
> > % xen-livepatch up foo.livepatch
> >
> > Would
On Tue, Apr 23, 2024 at 02:25:16PM +0200, Jan Beulich wrote:
> On 19.04.2024 12:02, Roger Pau Monne wrote:
> Then I wonder why it was this rather than ...
>
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -5,6 +5,7 @@
> > #include
> > #include
> > #include
> > +#include
On Tue, Apr 23, 2024 at 09:51:46AM +0200, Jan Beulich wrote:
> The ! clearly got lost by mistake.
>
> Fixes: e9e0eb30d4d6 ("x86/MTRR: avoid several indirect calls")
> Reported-by: Marek Marczykowski-Górecki
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks, Roger.
on
> > entry from PV or HVM specifically.
> >
> > Switch to use opt_bhb_entry_{pv,hvm} instead, and then remove
> > cpu_has_bhb_seq
> > since it no longer has any users.
> >
> > Reported-by: Jan Beulich
> > Fixes: 954c983abcee ('x86/spec-ctrl:
On Mon, Apr 22, 2024 at 12:57:55PM +0200, Jan Beulich wrote:
> On 22.04.2024 12:49, Roger Pau Monné wrote:
> > On Mon, Apr 22, 2024 at 10:25:40AM +0200, Jan Beulich wrote:
> >> On 22.04.2024 09:54, Roger Pau Monné wrote:
> >>> On Fri, Apr 19, 2024 at 04:34
On Mon, Apr 22, 2024 at 10:25:40AM +0200, Jan Beulich wrote:
> On 22.04.2024 09:54, Roger Pau Monné wrote:
> > On Fri, Apr 19, 2024 at 04:34:41PM +0200, Jan Beulich wrote:
> >> On 19.04.2024 12:50, Roger Pau Monné wrote:
> >>> On Fri, Apr 19, 2024 at 12:15
On Fri, Apr 19, 2024 at 04:34:41PM +0200, Jan Beulich wrote:
> On 19.04.2024 12:50, Roger Pau Monné wrote:
> > On Fri, Apr 19, 2024 at 12:15:19PM +0200, Jan Beulich wrote:
> >> On 19.04.2024 12:02, Roger Pau Monne wrote:
> >>> Livepatch payloads containing symbols th
payload
> > and hence must either be a Xen or a different livepatch payload symbol.
> >
> > Do not allow to resolve symbols that point to __init_begin, as that address
> > is
> > also unmapped. On the other hand, __init_end is not unmapped, and hence
> > allow
&
payload
> > and hence must either be a Xen or a different livepatch payload symbol.
> >
> > Do not allow to resolve symbols that point to __init_begin, as that address
> > is
> > also unmapped. On the other hand, __init_end is not unmapped, and hence
> > allow
On Fri, Apr 19, 2024 at 09:34:21AM +0100, Anthony PERARD wrote:
> On Mon, Apr 08, 2024 at 10:29:08AM +0100, Anthony PERARD wrote:
> > On Fri, Apr 05, 2024 at 04:54:30PM +0100, Anthony PERARD wrote:
> > > On Thu, Mar 28, 2024 at 05:54:04PM +, Anthony PERARD wrote:
> > > > On Mon, Mar 18, 2024
On Tue, Apr 02, 2024 at 11:49:20AM +0200, Jan Beulich wrote:
> On 28.03.2024 16:35, Roger Pau Monne wrote:
> > There's no reason to assume VGA text mode 3 to be unconditionally available.
> > With the addition of booting Xen itself in PVH mode there's a boot path that
> > explicitly short-circuits
On Tue, Apr 02, 2024 at 11:43:49AM +0200, Jan Beulich wrote:
> On 02.04.2024 11:38, Jan Beulich wrote:
> > On 28.03.2024 16:35, Roger Pau Monne wrote:
> >> Currently the offsets into the boot_video_info struct are manually encoded
> >> in
> >> video.S, which is fragile. Generate them in
On Thu, Apr 18, 2024 at 12:44:26PM +0200, Jan Beulich wrote:
> On 15.04.2024 16:17, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/spec_ctrl.c
> > +++ b/xen/arch/x86/spec_ctrl.c
> > @@ -643,7 +643,7 @@ static void __init print_details(enum ind_thunk thunk)
> > opt_eager_fpu
ing for "PE\0\0"
cannot be done using strncmp()."
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
LGTM (possibly pending the adjustment of the commit message):
Acked-by: Roger Pau Monné
One question below to ensure my understating is correct.
> ---
On Mon, Apr 15, 2024 at 09:17:08AM +0100, Anthony PERARD wrote:
> buster-backport isn't available on the main mirror anymore.
>
> Signed-off-by: Anthony PERARD
Acked-by: Roger Pau Monné
Please push ASAP.
Thanks, Roger.
On Mon, Apr 15, 2024 at 09:15:51AM +0100, Anthony PERARD wrote:
> On Fri, Apr 12, 2024 at 04:11:21PM +0200, Roger Pau Monne wrote:
> > The current timeout of 40s seems to be too low for AMD boxes (pinots and
> > rimavas) in the lab after XSA-455, see:
>
> There's something else we can tweak if
On Wed, Apr 10, 2024 at 08:33:48PM +0100, Andrew Cooper wrote:
> Resolves a MISRA R5.3 violation.
>
> Fixes: 622bdd962822 ("vpci/header: handle p2m range sets per BAR")
> Signed-off-by: Andrew Cooper
Acked-by: Roger Pau Monné
Thanks!
On Wed, Apr 10, 2024 at 05:21:37PM +0100, Andrew Cooper wrote:
> On 10/04/2024 4:14 pm, Roger Pau Monné wrote:
> > On Thu, Oct 26, 2023 at 09:55:39PM +0100, Andrew Cooper wrote:
> >> +
> >> +config AMD
> >> + bool "AMD"
> >> +default
ractical change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Wei Liu
> CC: Alejandro Vallejo
> CC: Stefano Stabellini
> CC: Xenia Ragiadakou
>
> I've intentionally ignored the other vendors for now. They can be put i
w maintainer since he has been
> > actively working on it for a while.
> >
> > Signed-off-by: Ross Lagerwall
>
> Acked-by: Konrad Rzeszutek Wilk
>
> Thank you for picking it up!
Acked-by: Roger Pau Monné
Thanks for your work on this Konrad.
Regards, Roger.
guests")
> Fixes: 478e4787fa64 ("x86/spec-ctrl: Expose RRSBA_CTRL to guests")
> Fixes: 583f1d095052 ("x86/spec-ctrl: Expose BHI_CTRL to guests")
> Signed-off-by: Andrew Cooper
Acked-by: Roger Pau Monné
Thanks, Roger.
been
> > unmapped by the time a livepatch gets loaded.
> >
> > Fix by adding a check that limits the clobbering of endbr64 instructions to
> > boot time only.
> >
> > Fixes: 37ed5da851b8 ('x86/altcall: Optimise away endbr64 instruction where
> > possible')
> &
On Thu, Mar 28, 2024 at 03:05:47PM +, Ross Lagerwall wrote:
> On Tue, Mar 19, 2024 at 10:07 AM Roger Pau Monné wrote:
> >
> > On Wed, Mar 13, 2024 at 03:07:43PM +, Ross Lagerwall wrote:
> > > Binaries may be built with entry points above 4G. While bootloaders may
&
y the optimization level, while gcc
> seems to always honor the function alignment passed in -falign-functions.
>
> Signed-off-by: Roger Pau Monné
> ---
> Changes since v5:
> - New in this version.
> ---
> xen/Kconfig | 5 +
> xen/Makefile | 1 +
> 2 files change
On Wed, Mar 27, 2024 at 08:22:41AM +0100, Jan Beulich wrote:
> On 26.03.2024 22:38, Jason Andryuk wrote:
> > 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
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
On Thu, Mar 21, 2024 at 10:17:25AM +0100, Jan Beulich wrote:
> On 21.03.2024 10:10, Roger Pau Monné wrote:
> > On Thu, Mar 21, 2024 at 09:07:10AM +0100, Jan Beulich wrote:
> >> On 20.03.2024 17:29, Roger Pau Monné wrote:
> >>> On Wed, Mar 20, 2024 at 04:09
On Thu, Mar 21, 2024 at 09:07:10AM +0100, Jan Beulich wrote:
> On 20.03.2024 17:29, Roger Pau Monné wrote:
> > On Wed, Mar 20, 2024 at 04:09:33PM +0100, Jan Beulich wrote:
> >> On 20.03.2024 14:57, Roger Pau Monne wrote:
> >>> There's no reason to force HVM guests
On Wed, Mar 20, 2024 at 03:51:55PM +0100, Jan Beulich wrote:
> On 20.03.2024 15:06, Roger Pau Monné wrote:
> > On Wed, Mar 20, 2024 at 11:58:50AM +0100, Jan Beulich wrote:
> >> On 20.03.2024 11:46, Roger Pau Monné wrote:
> >>> On Tue, Mar 19, 2024 at 02:28
rkaround
> ts-debian-*-install: Replace dots in hostnames by dashs
> ts-xen-install: Fix bridge setup, ask to copy MAC addr
> make-flight: Keep using buster for L2 guest in nested tests
> Temporally switch "qemu-mainline" branch to Bookworm
> Switch to Debian Bookw
On Mon, Mar 18, 2024 at 04:55:44PM +, Anthony PERARD wrote:
> Xen 4.17 doesn't build with Debian Bookworm. It fails to build
> IPXE/etherboot, on "amd64". So we keep using Debian Buster on Xen 4.18
> and earlier branches. Xen 4.18 builds 4.17 via job "build-amd64-prev".
>
> Xen 4.17 would
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 bookworm the default,
hence it seems pointless to switch QEMU just one patch
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 the test.
>
> Part of the logs from the host L0:
>
> > domain_crash
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, cubietruck-* installation works fine.
I'm kind of puzzled by this, as cubietruck
On Wed, Mar 20, 2024 at 04:09:33PM +0100, Jan Beulich wrote:
> On 20.03.2024 14:57, Roger Pau Monne wrote:
> > There's no reason to force HVM guests to have a valid vcpu_info area when
> > initializing a vCPU, as the vCPU can also be brought online using the local
> > APIC, and on that path
On Mon, Mar 18, 2024 at 04:55:11PM +, Anthony PERARD wrote:
> Newer version of Debian and thus git would use this automatically, no
> need to force it.
>
> Signed-off-by: Anthony PERARD
> ---
> Osstest/TestSupport.pm | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
gt; >
> > Fixes: 192df6f9122d ('x86: allow HVM guests to use hypercalls to bring up
> > vCPUs')
> > Signed-off-by: Roger Pau Monné
>
> Thanks for looking into this. But, do we actually need to force this on
> PV either?
Possibly, having now taken a look at the use
On Wed, Mar 20, 2024 at 11:58:50AM +0100, Jan Beulich wrote:
> On 20.03.2024 11:46, Roger Pau Monné wrote:
> > On Tue, Mar 19, 2024 at 02:28:12PM +0100, Jan Beulich wrote:
> >> With a02174c6c885 ("amd/iommu: clean up unused guest iommu related
> >> functions")
On Tue, Mar 19, 2024 at 02:46:59PM +, Ross Lagerwall wrote:
> On Tue, Mar 19, 2024 at 1:18 PM Roger Pau Monné wrote:
> >
> > On Wed, Mar 13, 2024 at 03:07:42PM +, Ross Lagerwall wrote:
> > > Currently, multiboot2-compatible bootloaders can load ELF binaries
On Tue, Mar 19, 2024 at 02:28:12PM +0100, Jan Beulich wrote:
> With a02174c6c885 ("amd/iommu: clean up unused guest iommu related
> functions") having removed the sole place where d->g_iommu would be set
> to non-NULL, guest_iommu_add_ppr_log() will unconditionally bail the
> latest from its 2nd
On Tue, Jan 09, 2024 at 03:38:34PM +, Alejandro Vallejo wrote:
> This allows toolstack to synthesise sensible topologies for guests. In
> particular, this patch causes x2APIC IDs to be packed according to the
> topology now exposed to the guests on leaf 0xb.
>
> Signed-off-by: Alejandro
On Tue, Jan 09, 2024 at 03:38:33PM +, Alejandro Vallejo wrote:
> Implements the helper for mapping vcpu_id to x2apic_id given a valid
> topology in a policy. The algo is written with the intention of extending
> it to leaves 0x1f and e26 in the future.
>
> Toolstack doesn't set leaf 0xb and
On Tue, Mar 19, 2024 at 05:20:35PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 09, 2024 at 03:38:29PM +, Alejandro Vallejo wrote:
> > This allows the initial x2APIC ID to be sent on the migration stream. The
> > hardcoded mapping x2apic_id=2*vcpu_id is maintained for the time b
On Tue, Jan 09, 2024 at 03:38:32PM +, Alejandro Vallejo wrote:
> As part of topology correction efforts, APIC IDs can no longer be derived
> strictly through the vCPU ID alone. Bring in the machinery for policy
> retrieval and parsing in order to generate the proper MADT table and wake
> the
the requirement for 'e' to be page aligned. All this is doing is
> forcing work for the caller just to satisfy an assertion.
>
> Reported-by: Jan Beulich
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
One suggestion below.
> ---
> CC: Jan Beulich
> CC: Roger P
On Tue, Jan 09, 2024 at 03:38:30PM +, Alejandro Vallejo wrote:
> Move struct xc_cpu_policy data structure out of xg_private.h and into
> the public xenguest.h so it can be used by libxl.
I will let Andrew comment on this one, IIRC the initial idea was to
not leak cpu_policy into libxl, and to
On Tue, Jan 09, 2024 at 03:38:29PM +, Alejandro Vallejo wrote:
> This allows the initial x2APIC ID to be sent on the migration stream. The
> hardcoded mapping x2apic_id=2*vcpu_id is maintained for the time being.
> Given the vlapic data is zero-extended on restore, fix up migrations from
>
On Wed, Mar 13, 2024 at 03:07:42PM +, Ross Lagerwall wrote:
> Currently, multiboot2-compatible bootloaders can load ELF binaries and
> a.out binaries. The presence of the address header tag determines
> how the bootloader tries to interpret the binary (a.out if the address
> tag is present
On Thu, Mar 14, 2024 at 02:24:31PM +, Ross Lagerwall wrote:
> On Thu, Mar 14, 2024 at 1:37 PM Jan Beulich wrote:
> >
> > On 14.03.2024 10:30, Ross Lagerwall wrote:
> > > On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich wrote:
> > >>
> > >> On 13.03.2024 16:07, Ross Lagerwall wrote:
> > >>> In
On Wed, Mar 13, 2024 at 03:07:43PM +, Ross Lagerwall wrote:
> Binaries may be built with entry points above 4G. While bootloaders may
> relocate them below 4G, it should be possible for the binary to specify
> those entry points. Therefore, extend the multiboot2 protocol such that
> 64 bit
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 Marczykowski-Górecki
>
> In principle
> Acked-by: Jan Beulich
> However, ...
>
>
ow2
> + test-amd64-amd64-xl-raw
> + test-armhf-armhf-libvirt-vhd
> + test-armhf-armhf-xl-qcow2
> + test-armhf-armhf-xl-raw
>
> Anthony PERARD (3):
> make-fligh: Fix freebsd guest test test-id
> mfi-common: Rework toolstack-disk_format test matrix
> ap-common: Switch to Linux 6.1 by default on x86 + drop dom0 i386
Acked-by: Roger Pau Monné
Thanks, Roger.
he loop is
> doing.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Thanks, Roger.
all CPUs: {0-511} stuck
>
> Signed-off-by: Andrew Cooper
One thing has to be said about the previous message: it was hard to
not see it when all CPUs on the system failed the watchdog test.
Reviewed-by: Roger Pau Monné
Thanks.
he loop is
> doing.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Roger Pau Monné
>
> Noticed when looking at the ffs() code gen improvements.
>
> Any suggestion on how to test this? test_vcpi doesn't seem to check anything
> here. I think I've got the boundary condit
On Thu, Mar 14, 2024 at 12:59:19PM -0400, Jason Andryuk wrote:
> On 2024-03-14 11:30, Jan Beulich wrote:
> > On 14.03.2024 15:33, Roger Pau Monné wrote:
> > > On Thu, Mar 14, 2024 at 09:51:22AM -0400, Jason Andryuk wrote:
> > > > On 2024-03-14 05:48, Roger Pau Monné w
On Thu, Mar 14, 2024 at 04:30:05PM +0100, Jan Beulich wrote:
> On 14.03.2024 15:33, Roger Pau Monné wrote:
> > On Thu, Mar 14, 2024 at 09:51:22AM -0400, Jason Andryuk wrote:
> >> On 2024-03-14 05:48, Roger Pau Monné wrote:
> >>> On Wed, Mar 13, 2024 at 03:30:2
On Thu, Mar 14, 2024 at 09:51:22AM -0400, Jason Andryuk wrote:
> On 2024-03-14 05:48, Roger Pau Monné wrote:
> > On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote:
> > > Xen tries to load a PVH dom0 kernel at the fixed guest physical address
> > > from
On Thu, Mar 14, 2024 at 09:28:43PM +0800, flyingpeng...@gmail.com wrote:
> From: Peng Hao
>
> Use kmap_local_page() instead of kmap_atomic() which has been
> deprecated.
>
> Signed-off-by: Peng Hao
Acked-by: Roger Pau Monné
Thanks, Roger.
On Thu, Mar 14, 2024 at 08:06:27AM +0100, Jan Beulich wrote:
> On 14.03.2024 00:40, Stefano Stabellini wrote:
> > Roger kindly volunteered to step up as IOMMU Maintainer.
> >
> > Signed-off-by: Stefano Stabellini
>
> Acked-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks.
On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote:
> 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
On Tue, Mar 12, 2024 at 05:19:46PM +, Anthony PERARD wrote:
> On Mon, Mar 11, 2024 at 06:27:52PM +0100, Roger Pau Monné wrote:
> > On Wed, Mar 06, 2024 at 11:47:41AM +, Anthony PERARD wrote:
> > > Gone, but replaced by a new test-amd64-amd64-*:
> > > -
On Wed, Dec 13, 2023 at 05:10:50PM +0100, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> The xen sources contain violations of MISRA C:2012 Rule 14.4 whose
> headline states:
> "The controlling expression of an if statement and the controlling
> expression of an iteration-statement
On Mon, Mar 11, 2024 at 09:33:11PM +0100, 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 itself are included in the mapping, those
> are
On Wed, Mar 06, 2024 at 11:47:41AM +, Anthony PERARD wrote:
> linux-4.19 branch in xenbits is outdated, it haven't been updated and
> tested since 2020 as it has been disabled in osstest. Also, this 4.19
> branch doesn't build on Bookworm.
>
> So we will start to use a newer version of Linux.
On Thu, Mar 07, 2024 at 11:08:37AM +0100, Jan Beulich wrote:
> On 07.03.2024 11:00, Roger Pau Monné wrote:
> > On Wed, Mar 06, 2024 at 01:50:29PM -0500, Jason Andryuk wrote:
> >> Xen tries to load a PVH dom0 kernel at the fixed guest physical address
> >> from
On Wed, Mar 06, 2024 at 01:50:29PM -0500, Jason Andryuk wrote:
> 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
On Wed, Mar 06, 2024 at 01:50:32PM -0500, Jason Andryuk wrote:
> 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
ude/public/sched.h (starting L158)
>
> Suggested-by: Roger Pau Monné
> Signed-off-by: Cyril Rébert / zithro
Thanks for doing this, Anthony already provided some feedback.
> ---
> docs/man/xl.1.pod.in | 34 ++
> 1 file changed, 34 insertions(+)
On Wed, Mar 06, 2024 at 01:15:48PM +0800, flyingpeng...@gmail.com wrote:
> From: Peng Hao
>
> From: Peng Hao
>
> Use kmap_local_page() instead of kmap_atomic() which has been
> deprecated.
>
> Signed-off-by: Peng Hao
> ---
> drivers/block/xen-blkback/blkback.c | 4 ++--
> 1 file changed, 2
3 only manifested in non-debug builds due to
> the usage of -O2.
>
> Duplicate the clang based test in order to test with both debug and non-debug
> Xen builds.
>
> Signed-off-by: Roger Pau Monné
> ---
> automation/gitlab-ci/test.yaml | 18 --
> 1
r to also inflate it when running as
> > PVH. onvert UNUSABLE regions up to the ratio specified in EXTRA_MEM_RATIO
> > to
> > RAM, while reserving them using xen_add_extra_mem() (which is also moved so
> > it's no longer tied to CONFIG_PV).
> >
> > Signed-off-
_lite((unsigned long)region->rodata_start,
> > + ROUNDUP((unsigned
> > long)region->rodata_end, PAGE_SIZE),
>
> I missed the final refresh to turn this to PAGE_ALIGN(). Fixed locally.
With that:
Reviewed-by: Roger Pau Monné
Thanks, Roger.
On Tue, Mar 05, 2024 at 12:11:20PM +, Andrew Cooper wrote:
> These are optional. .init doesn't distinguish types of data like this, and
> livepatches don't necesserily have any .rodata either.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger
functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Thanks, Roger.
> low RAM.
>
> Reported-by: Neowutran
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
> ---
> If we wanted to fit e.g. multiple 1Gb BARs, it would likely be prudent
> to similarly avoid low RAM relocation in the first place. Yet accounting
> for things differently
On Mon, Mar 04, 2024 at 02:25:45PM +0100, Jan Beulich wrote:
> On 04.03.2024 11:02, Roger Pau Monné wrote:
> > On Mon, Mar 04, 2024 at 08:32:22AM +0100, Jan Beulich wrote:
> >> BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of
> >> the
s) fall back to general x86.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks.
On Mon, Mar 04, 2024 at 08:32:22AM +0100, Jan Beulich wrote:
> BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of
> the lower 2Gb range and the top of the higher 2Gb range have special
> purpose. Don't even have them influence whether to (perhaps) relocate
> low RAM.
Here
On Mon, Mar 04, 2024 at 08:54:34AM +0100, Jan Beulich wrote:
> On 01.03.2024 13:42, Roger Pau Monne wrote:
> > The current usage of a cmpxchg loop to increase the value of page count is
> > not
> > optimal on amd64, as there's already an instruction to do an atomic add to a
> > 64bit integer.
> >
On Fri, Mar 01, 2024 at 03:01:36PM +, Andrew Cooper wrote:
> On 01/03/2024 1:28 pm, Roger Pau Monné wrote:
> > On Thu, Feb 29, 2024 at 06:13:54PM +, Andrew Cooper wrote:
> >> MD_CLEAR and FB_CLEAR need OR-ing across a migrate pool. Allow this, by
> >> having the
-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Wei Liu
> ---
> xen/arch/x86/cpu-policy.c | 24 +
> xen/include/public/arch-x86/cpufeatureset.h | 4 ++--
> 2 files changed, 26 insertions(+), 2 deletion
api is slowly growing the logic to check a VM
> against the target max policy.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
I have one question below.
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Wei Liu
> ---
> xen/arch/x86/cpu-policy.c
o sets of APIC_IDs are from different address spaces.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Thanks, Roger.
sage if neither HAP or Shadow are
> available.
>
> Signed-off-by: Andrew Cooper
Acked-by: Roger Pau Monné
One comment below.
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Wei Liu
> ---
> tools/tests/resource/test-resource.c | 25 +
> 1
On Thu, Feb 29, 2024 at 02:12:26PM +0100, Jan Beulich wrote:
> On 29.02.2024 14:01, Jan Beulich wrote:
> > On 29.02.2024 13:40, Roger Pau Monné wrote:
> >> On Thu, Feb 29, 2024 at 01:11:55PM +0100, Jan Beulich wrote:
> >>> On 29.02.2024 10:55, Roger Pau Mo
On Thu, Feb 29, 2024 at 01:11:55PM +0100, Jan Beulich wrote:
> On 29.02.2024 10:55, Roger Pau Monne wrote:
> > --- a/README
> > +++ b/README
> > @@ -41,7 +41,7 @@ provided by your OS distributor:
> > - GCC 4.1.2_20070115 or later
> > - GNU Binutils 2.16.91.0.5 or later
> >
1 - 100 of 5574 matches
Mail list logo
