On 08.09.2025 11:35, Gerald Elder-Vass wrote:
>>> + size == 1 && data == 0) )
>>
>> ... any reason it's literal 1 here?
>
> The size variable is also used as output from GetVariable and we should
> verify that the size of the returned data is as expected, it is simply one
> byte so probab
Somewhat, but in the regular case where enter() is called followed by
leave() there is really no complexity for the caller, just an extra
local variable.
There are complications where we want to exit lazy_mmu temporarily, as
in mm/kasan/shadow.c [1k], but this is in fact unavoidable. Chatting
wi
On 10.09.2025 23:57, Andrew Cooper wrote:
> On 10/09/2025 7:58 pm, Jason Andryuk wrote:
>> Hi,
>>
>> We're running Android as a guest and it's running the Compatibility
>> Test Suite. During the CTS, the Android domU is rebooted multiple times.
>>
>> In the middle of the CTS, we've seen reboot fai
On 10.09.2025 09:38, Penny Zheng wrote:
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -55,8 +55,8 @@ struct xsm_ops {
> void (*security_domaininfo)(struct domain *d,
> struct xen_domctl_getdomaininfo *info);
> int (*domain_create)(struct
On 11.09.2025 18:23, Alejandro Vallejo wrote:
> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
> by the device model. The GPE handler checks this and compares it against
> the "online" flag on each MADT LAPIC entry, setting the flag to its
> related bit in the bitmap and a
On 05.09.2025 14:10, Gerald Elder-Vass wrote:
> @@ -1047,6 +1056,46 @@ static UINTN __init
> efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> return gop_mode;
> }
>
> +static void __init efi_verify_kernel(EFI_HANDLE ImageHandle)
> +{
> +static EFI_GUID __initdata shim_image_guid
On 10.09.2025 09:38, Penny Zheng wrote:
> Function xsm_vm_event_control() is only invoked under CONFIG_VM_EVENT, so
> it shall be wrapped with it
Isn't this addressing a Misra violation then? Whether it's "unreachable code"
or "dead code" I can't really tell; I don't think I have properly understo
On Tue, Sep 09, 2025 at 04:27:31PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
<...>
> include/linux/page-flags.h | 1 +
<...>
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -614,6 +614,7 @@ FOLIO_FLAG(dropbehind, FOLIO_HEAD_PAGE)
> * available
Support Shim LoadImage protocol but keep Shim Lock for compatibility
https://gitlab.com/xen-project/people/geraldev/xen/-/pipelines/2029800410
- Saw known unrelated debian-12-x86_64 issue
Gerald Elder-Vass (1):
efi: Support using Shim's LoadImage protocol
Ross Lagerwall (1):
efi: Add a funct
On 10/09/2025 17:37, David Hildenbrand wrote:
>>
>> Somewhat, but in the regular case where enter() is called followed by
>> leave() there is really no complexity for the caller, just an extra
>> local variable.
>>
>> There are complications where we want to exit lazy_mmu temporarily, as
>> in mm/k
On 11.09.2025 13:53, Alejandro Vallejo wrote:
> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
> by the device model. The GPE handler checks this and compares it against
> the "online" flag on each MADT LAPIC entry, setting the flag to its
> related bit in the bitmap and a
On 10/09/2025 2:11 pm, Andrew Cooper wrote:
> On 10/09/2025 12:57 pm, Marek Marczykowski-Górecki wrote:
>> On Wed, Sep 10, 2025 at 12:34:16PM +0100, Andrew Cooper wrote:
>>> Testing on staging-4.19 is hitting a reliable failure, caused by alpine/3.18
>>> being a root build container, but debian/12-
On 9/10/25 3:36 PM, Jan Beulich wrote:
On 10.09.2025 15:26, Andrew Cooper wrote:
On 03/09/2025 8:55 am, Jan Beulich wrote:
Along the lines of what b89f8f054f96 ("x86/apic: Drop sync_Arb_IDs()")
said, the function is dead logic as well: All 64-bit capable Intel systems
have (at least) xAPIC (if
The only user of paravirt_sched_clock() is in tsc.c, so move the code
from paravirt.c and paravirt.h to tsc.c.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt.h| 12
arch/x86/include/asm/timer.h | 1 +
arch/x86/kernel/kvmclock.c | 1 +
arch/x86/ker
On 11.09.2025 23:20, Jason Andryuk wrote:
> Thanks, everyone.
>
> On 2025-09-10 17:57, Andrew Cooper wrote:
>> On 10/09/2025 7:58 pm, Jason Andryuk wrote:
>>> Hi,
>>>
>>> We're running Android as a guest and it's running the Compatibility
>>> Test Suite. During the CTS, the Android domU is reboot
Function vm_event_is_enabled() is introduced to check if vm event is enabled,
and also make the checking conditional upon CONFIG_VM_EVENT, which could help
DCE a lot calls/codes, such as hvm_monitor_io(), etc when VM_EVENT=n.
In-place assertion of arch.vm_event is kinds of redundant and could be
re
Hi,
Both patches are independent Patch 2 can very well go in before patch 1.
pipeline:
https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2034774204
(still running as of now)
v1:
https://lore.kernel.org/xen-devel/2025095308.16580-1-alejandro.garciavall...@amd.com/
origi
The lazy_mmu API now allows nested sections to be handled by arch
code: enter() can return a flag if called inside another lazy_mmu
section, so that the matching call to leave() leaves any
optimisation enabled.
This patch implements that new logic for powerpc: if there is an
active batch, then ent
On Tue, Sep 09, 2025 at 10:37:48PM +0300, Leon Romanovsky wrote:
> On Tue, Sep 09, 2025 at 04:27:31PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky
>
> <...>
>
> > include/linux/page-flags.h | 1 +
>
> <...>
>
> > --- a/include/linux/page-flags.h
> > +++ b/include/linux/page
On Mon, 8 Sep 2025 08:39:26 +0100 Kevin Brodsky wrote:
> arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
> (taking and returning no value). This is proving problematic in
> situations where leave() needs to restore some context back to its
> original state (before enter() was c
[Public]
> -Original Message-
> From: Penny, Zheng
> Sent: Thursday, September 11, 2025 3:16 PM
> To: Jan Beulich
> Cc: Huang, Ray ; Andrew Cooper
> ; Roger Pau Monné ; xen-
> de...@lists.xenproject.org
> Subject: RE: [PATCH v2 03/26] xen/x86: consolidate vram tracking support
>
>
>
> > -
Hi Oleksii,
While going through the list of recently committed patches, I noticed
some changes in the relinquish code.
On 04/09/2025 15:21, Oleksii Moisieiev wrote:
@@ -1103,6 +1109,10 @@ int domain_relinquish_resources(struct domain *d)
ret = relinquish_p2m_mapping(d);
i
On 03/09/2025 8:55 am, Jan Beulich wrote:
> Along the lines of what b89f8f054f96 ("x86/apic: Drop sync_Arb_IDs()")
> said, the function is dead logic as well: All 64-bit capable Intel systems
> have (at least) xAPIC (if not x2APIC).
>
> Even if Eclair can't know it, such code is violating Misra rul
On 08.09.25 09:39, Kevin Brodsky wrote:
arch_{enter,leave}_lazy_mmu_mode() currently have a stateless API
(taking and returning no value). This is proving problematic in
situations where leave() needs to restore some context back to its
original state (before enter() was called). In particular, t
On 11.09.2025 04:37, Stefano Stabellini wrote:
> On Wed, 10 Sep 2025, Penny Zheng wrote:
>> Function xsm_set_target() is only invoked under XEN_DOMCTL_set_target
>> domctl-op, and shall be wrapped with CONFIG_MGMT_HYPERCALLS.
>>
>> Signed-off-by: Penny Zheng
>> ---
>> v1 -> v2:
>> - adapt to chang
On 11/09/2025 12:53 pm, Alejandro Vallejo wrote:
> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
> by the device model. The GPE handler checks this and compares it against
> the "online" flag on each MADT LAPIC entry, setting the flag to its
> related bit in the bitmap an
On 09/09/2025 11:21, David Hildenbrand wrote:
> On 09.09.25 04:16, Andrew Morton wrote:
>> On Mon, 8 Sep 2025 08:39:24 +0100 Kevin Brodsky
>> wrote:
>>
>>> The main change enabling nesting is patch 2, following the approach
>>> suggested by Catalin Marinas [4]: have enter() return some state and
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Monday, September 8, 2025 6:02 PM
> To: Penny, Zheng
> Cc: Andryuk, Jason ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v9 1/8] xen/cpufreq: embed hwp into struct
> cpufreq_policy{}
>
> (re-adding the list)
>
> On 05.09.
On Fri, Sep 12, 2025 at 12:12:13AM +0100, Andrew Cooper wrote:
> Everything works fine with Debian 13. Provide two new build jobs (for a total
> of 6), and update the test jobs.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Denis Mukhin
On Fri, Sep 12, 2025 at 12:12:14AM +0100, Andrew Cooper wrote:
> cpio needs to be in Tools (general) now that it's used by the general build
> script. Merge the rest of the test phase jobs into one group, to avoid being
> overly fine-grain.
>
> No functional change.
>
> Signed-off-by: Andrew Coo
Hi Jan,
On Wed, Sep 3, 2025 at 7:31 AM Mykola Kvach wrote:
>
> Hi Jan,
>
> On Tue, Sep 2, 2025 at 5:33 PM Jan Beulich wrote:
> >
> > On 02.09.2025 00:10, Mykola Kvach wrote:
> > > --- a/xen/common/domain.c
> > > +++ b/xen/common/domain.c
> > > @@ -1317,7 +1317,11 @@ int domain_shutdown(struct do
On 08/09/2025 17:31, Oleksii Kurochko wrote:
> Hello Oleksii,
> On 9/8/25 4:21 PM, Oleksii Moisieiev wrote:
>> On 08/09/2025 17:11, Oleksii Kurochko wrote:
>>> Hello everyone,
>>> Based on the message from the previous version, the MISRA issues have been
>>> fixed,
>>> and aside from one remaini
On Fri, Sep 12, 2025 at 12:12:14AM +0100, Andrew Cooper wrote:
> cpio needs to be in Tools (general) now that it's used by the general build
> script. Merge the rest of the test phase jobs into one group, to avoid being
> overly fine-grain.
>
> No functional change.
>
> Signed-off-by: Andrew Coo
The OVMF package in Debian Trixie has _4M suffixes on the files. Have
scripts/include/xtf-x86-64-efi check for this before falling back to no
suffix.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabell
On Fri, Sep 12, 2025 at 12:12:15AM +0100, Andrew Cooper wrote:
> With the exception of the custom IBT job, copy all Debian 12 jobs making
> Debian 13 versions, then trim the Debian 12 ranconfig jobs.
>
> Update the test jobs using Debian 12 to use 13.
>
> Signed-off-by: Andrew Cooper
Reviewed-b
On Fri, Sep 12, 2025 at 12:12:16AM +0100, Andrew Cooper wrote:
> Also state the RISC-V baseline now it's been set, as it's the reason why
> RISC-V Bullseye got dropped.
>
> Signed-off-by: Andrew Cooper
> Acked-by: Oleksii Kurochko
Reviewed-by: Denis Mukhin
> ---
> CC: Anthony PERARD
> CC: M
On Fri, Sep 12, 2025 at 02:15:34AM +0100, Andrew Cooper wrote:
> The OVMF package in Debian Trixie has _4M suffixes on the files. Have
> scripts/include/xtf-x86-64-efi check for this before falling back to no
> suffix.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Denis Mukhin
Hello everyone,
I would like to inform you that the release schedule has been updated due to
an extension of the Feature Freeze.
The Code Freeze is now scheduled for*Friday, October 3, 2025*.
You can find the updated schedule here:
https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Note
On Fri, Sep 12, 2025 at 12:12:12AM +0100, Andrew Cooper wrote:
> This was missed when introducing Trixie.
>
> Fixes: aad6ebf0596f ("CI: Update riscv64 to use Debian Trixie")
> Signed-off-by: Andrew Cooper
Reviewed-by: Denis Mukhin
> ---
> CC: Anthony PERARD
> CC: Michal Orzel
> CC: Jan Beul
Everything works fine with Debian 13. Provide two new build jobs (for a total
of 6), and update the test jobs.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Shawn Anastasio
CC: Oleksii K
With the exception of the custom IBT job, copy all Debian 12 jobs making
Debian 13 versions, then trim the Debian 12 ranconfig jobs.
Update the test jobs using Debian 12 to use 13.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger
This was missed when introducing Trixie.
Fixes: aad6ebf0596f ("CI: Update riscv64 to use Debian Trixie")
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Shawn Anastasio
CC: Oleksii Kurochko
Also state the RISC-V baseline now it's been set, as it's the reason why
RISC-V Bullseye got dropped.
Signed-off-by: Andrew Cooper
Acked-by: Oleksii Kurochko
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Oleksii Kuro
Refreshed the Trixie series. See patches for details.
These containers are already built and deployed for people to test with.
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2035442869
Andrew Cooper (5):
CI: Use the Debian Trixie container for RISC-V test jobs
CI: Update pp
Thanks, everyone.
On 2025-09-10 17:57, Andrew Cooper wrote:
On 10/09/2025 7:58 pm, Jason Andryuk wrote:
Hi,
We're running Android as a guest and it's running the Compatibility
Test Suite. During the CTS, the Android domU is rebooted multiple times.
In the middle of the CTS, we've seen reboot
On 09.09.2025 15:27, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Changelog:
> v6:
> * Based on "dma-debug: don't enforce dma mapping check on noncoherent
> allocations" patch.
> * Removed some unused variables from kmsan conversion.
> * Fixed missed ! in dma check.
> v5: https://l
On 10.09.2025 07:26, Leon Romanovsky wrote:
> On Tue, Sep 09, 2025 at 10:37:48PM +0300, Leon Romanovsky wrote:
>> On Tue, Sep 09, 2025 at 04:27:31PM +0300, Leon Romanovsky wrote:
>>> From: Leon Romanovsky
>> <...>
>>
>>> include/linux/page-flags.h | 1 +
>> <...>
>>
>>> --- a/include/lin
On the other hand, with a pagefault_disabled-like approach, there is no
way to instruct call {3} to fully exit lazy_mmu regardless of the
nesting level.
Sure there is, with a better API. See below. :)
I meant while keeping the existing shape of the API but yes fair enough!
Time to do it prop
[Resend from an account which will let me...]
On 11/09/2025 4:46 pm, Alejandro Vallejo wrote:
> On Thu Sep 11, 2025 at 9:55 AM CEST, Jan Beulich wrote:
>> On 10.09.2025 23:57, Andrew Cooper wrote:
>>> On 10/09/2025 7:58 pm, Jason Andryuk wrote:
Hi,
We're running Android as a guest a
On Thu Sep 11, 2025 at 10:24 AM CEST, Gerald Elder-Vass wrote:
> Commit cb41b4ce14a9 introduced init_secure_boot_mode but one line was
> not wrapped appropriately.
>
> Signed-off-by: Gerald Elder-Vass
> ---
> CC: Marek Marczykowski-Górecki
> CC: "Daniel P. Smith"
> CC: Jan Beulich
> CC: Andrew
PVH guests have no DM, so this causes the guest to fetch the online CPU
bitmap from an unbacked 0xaf00 PIO port when executing the GPE handler.
Seeing how ACPI CPU hotplug is the only event delivered via GPE, remove
the GPE handler in addition to anything ACPI CPU hotplug related.
This shrinks PV
CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
by the device model. The GPE handler checks this and compares it against
the "online" flag on each MADT LAPIC entry, setting the flag to its
related bit in the bitmap and adjusting the table's checksum.
The bytecode doesn't,
On 11/09/2025 14:06, Alexander Gordeev wrote:
> On Wed, Sep 10, 2025 at 06:11:54PM +0200, Kevin Brodsky wrote:
>
> Hi Kevin,
>
>> On 09/09/2025 16:38, Alexander Gordeev wrote:
>>> Would that integrate well with LAZY_MMU_DEFAULT etc?
>> Hmm... I though the idea is to use LAZY_MMU_* by archit
On Thu Sep 11, 2025 at 9:55 AM CEST, Jan Beulich wrote:
> On 10.09.2025 23:57, Andrew Cooper wrote:
>> On 10/09/2025 7:58 pm, Jason Andryuk wrote:
>>> Hi,
>>>
>>> We're running Android as a guest and it's running the Compatibility
>>> Test Suite. During the CTS, the Android domU is rebooted multip
Hi,
The steps:
1. Have domU netfront ("untrusted" here) and domU netback
("sys-firewall-alt" here).
2. Pause frontend
3. Shutdown backend
4. Unpause frontend
5. Detach network (in my case attaching another one follows just after,
but I believe it's not relevant).
This gives the following on the f
On 11/09/2025 1:35 pm, Alejandro Vallejo wrote:
> On Thu Sep 11, 2025 at 2:03 PM CEST, Andrew Cooper wrote:
>> On 11/09/2025 12:53 pm, Alejandro Vallejo wrote:
>>> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
>>> by the device model. The GPE handler checks this and compa
On 10.09.2025 09:38, Penny Zheng wrote:
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -151,8 +151,17 @@ void arch_dump_domain_info(struct domain *d);
>
> int arch_vcpu_reset(struct vcpu *v);
>
> +#ifdef CONFIG_MGMT_HYPERCALLS
> bool domctl_lock_acquire(void);
> void
On 10.09.2025 09:38, Penny Zheng wrote:
> The following functions are xsm-related and only invoked under arch-specific
> domctl-op, so they shall all be wrapped with CONFIG_MGMT_HYPERCALLS:
> - xsm_domctl
Doesn't this come too early (reflected by you putting #ifdef inside the
function), while ...
On Thu Sep 11, 2025 at 2:03 PM CEST, Andrew Cooper wrote:
> On 11/09/2025 12:53 pm, Alejandro Vallejo wrote:
>> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
>> by the device model. The GPE handler checks this and compares it against
>> the "online" flag on each MADT LAPI
On 11.09.2025 05:22, Stefano Stabellini wrote:
> On Wed, 10 Sep 2025, Penny Zheng wrote:
>> Users control/monitor Intel Platform Shared Resource (PSR) through
>> related domctl-op or sysctl-op, so CONFIG_X86_PSR can be put under
>> MGMT_HYPERCALLS. With this change, we could remove MGMT_HYPERCALLS-
On Wed, Sep 10, 2025 at 06:11:54PM +0200, Kevin Brodsky wrote:
Hi Kevin,
> On 09/09/2025 16:38, Alexander Gordeev wrote:
> > Would that integrate well with LAZY_MMU_DEFAULT etc?
> Hmm... I though the idea is to use LAZY_MMU_* by architectures that
> want to use it - at least that is
On 10.09.2025 09:38, Penny Zheng wrote:
> The following functions are xsm-related and only invoked under iommu-related
> domctl-op and shall all be wrapped with CONFIG_MGMT_HYPERCALLS:
> - xsm_get_device_group
> - xsm_assign_device
> - xsm_deassign_device
> - xsm_assign_dtdevice
> - xsm_deassign_dt
On 10.09.2025 09:38, Penny Zheng wrote:
> Function iommu_do_domctl() is the main entry for all iommu-related domctl-op,
> and shall be wrapped with CONFIG_MGMT_HYPERCALLS.
> Tracking its calling chain, the following functions shall all be wrapped
> with CONFIG_MGMT_HYPERCALLS:
> - iommu_do_pci_domc
Hi,
This series is a follow-up to a prior patch to remove ACPI CPU hotplug AML from
PVH guests. Between now and then the working assumption for the corruption has
been identified to be more general than PVH. This series rewords the commit
message for that patch (which became patch 2 in this series
PVH guests have no DM, so this causes the guest to fetch the online CPU
bitmap from an unbacked 0xaf00 PIO port when executing the GPE handler.
Seeing how ACPI CPU hotplug is the only event delivered via GPE, remove
the GPE handler in addition to anything ACPI CPU hotplug related.
This shrinks PV
On 10.09.2025 09:38, Penny Zheng wrote:
> Arch-specific domain_set_time_offset() is responisble for
> XEN_DOMCTL_settimeoffset domctl-op, and shall be wrapped with
> CONFIG_MGMT_HYPERCALLS
> Wrap XEN_DOMCTL_settimeoffset-case transiently with CONFIG_MGMT_HYPERCALLS,
> and it will be removed when in
On 10.09.2025 09:38, Penny Zheng wrote:
> Function xsm_vm_event_control() is only invoked under CONFIG_VM_EVENT, so
> it shall be wrapped with it
>
> Signed-off-by: Penny Zheng
> ---
> v1 -> v2:
> - new commit
> ---
> xen/include/xsm/xsm.h | 4 ++--
> xen/xsm/dummy.c | 2 +-
> xen/xsm/flas
On 10.09.2025 09:38, Penny Zheng wrote:
> @@ -508,13 +510,21 @@ static inline int xsm_unbind_pt_irq(
> static inline int xsm_irq_permission(
> xsm_default_t def, struct domain *d, int pirq, uint8_t allow)
> {
> +#ifdef CONFIG_MGMT_HYPERCALLS
> return alternative_call(xsm_ops.irq_permiss
On 11.09.2025 04:31, Stefano Stabellini wrote:
> On Wed, 10 Sep 2025, Penny Zheng wrote:
>> Arch-specific function arch_get_info_guest() is responsible for
>> XEN_DOMCTL_getvcpucontext domctl-op, and shall be wrapped with
>> CONFIG_MGMT_HYPERCALLS
>> Wrap XEN_DOMCTL_getvcpucontext-case transiently
On 10.09.2025 09:38, Penny Zheng wrote:
> --- a/xen/common/sched/arinc653.c
> +++ b/xen/common/sched/arinc653.c
> @@ -735,8 +735,8 @@ static const struct scheduler sched_arinc653_def = {
>
> .switch_sched = a653_switch_sched,
>
> -.adjust = NULL,
This line can just be droppe
On 11.09.2025 11:20, Penny, Zheng wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Wednesday, September 10, 2025 10:57 PM
>>
>> On 10.09.2025 09:38, Penny Zheng wrote:
>>> --- a/xen/include/xen/vm_event.h
>>> +++ b/xen/include/xen/vm_event.h
>>> @@ -50,6 +50,7 @@ struct vm_event_
From: Grygorii Strashko
Restrict cpu_up_send_sgi() function to arm32 code as it's used by arm32
platforms only and unreachable on arm64 (Misra rule 2.1).
Signed-off-by: Grygorii Strashko
---
Logically cpu_up_send_sgi() should be moved in arm32, but source is
"GPL-2.0-or-later" while possible de
>> @@ -1078,11 +1078,12 @@ static void __init efi_verify_kernel(EFI_HANDLE
ImageHandle)
>> verified = true;
>>
>> /*
>> - * Always unload the image. We only needed LoadImage() to
perform
>> - * verification anyway, and in the case of a failure there may
still
A previous series for supporting Shim's LoadImage protocol had some
outstanding comments after it had been accepted, and internal review
revealed an improvement to be safe when unloading the image.
This patch series includes those changes.
https://gitlab.com/xen-project/people/geraldev/xen/-/pipe
From: Grygorii Strashko
Now Arm64 AArch32 EL1 guest support is always enabled and built-in while
not all Arm64 platforms supports AArch32 (for example on Armv9A) or this
support might not be needed (Arm64 AArch32 is used quite rarely in embedded
systems). More over, when focusing on safety certif
On 11.09.2025 10:24, Gerald Elder-Vass wrote:
> @@ -1078,11 +1078,12 @@ static void __init efi_verify_kernel(EFI_HANDLE
> ImageHandle)
> verified = true;
>
> /*
> - * Always unload the image. We only needed LoadImage() to perform
> - * verification anyway,
Commit 59a1d6d3ea1e introduced Shim's LoadImage protocol and unloads the
image after loading it (for verification purposes) regardless of the
returned status. The protocol API implies this is the correct behaviour
but we should add a check to protect against the unlikely case this
frees any memory
Other projects have long switched to xz and/or lzip.
Tidy things some as well: With the removal of qemu from the tarball,
intermediately extracting the tarball again has become wasteful. Drop
that. Invoke compressors using asynchronous lists, to reduce overall
latency. Drop the -v option from the
Commit cb41b4ce14a9 introduced init_secure_boot_mode but one line was
not wrapped appropriately.
Signed-off-by: Gerald Elder-Vass
---
CC: Marek Marczykowski-Górecki
CC: "Daniel P. Smith"
CC: Jan Beulich
CC: Andrew Cooper
CC: Anthony PERARD
CC: Michal Orzel
CC: Julien Grall
CC: "Roger Pau M
From: Grygorii Strashko
Split set_domain_type() between Arm64/Arm32 sub-arches as
set_domain_type() implementation is going to be extended for Arm64.
Signed-off-by: Grygorii Strashko
---
v3:
- mark domain-build.c as "init.o" for make
v2:
- no changes, rebase
xen/arch/arm/arm32/Makefile
From: Grygorii Strashko
Split is_32bit/64bit_domain() macro implementations between arm64/arm32.
Signed-off-by: Grygorii Strashko
Reviewed-by: Volodymyr Babchuk
---
v3:
- no changes, add tag
v2:
- fix comments related to macro parameters evaluation issues
xen/arch/arm/include/asm/arm32/doma
From: Grygorii Strashko
Hi,
During review of v1 [1] of this series Julien Grall raised concern that
"If the desire is to make 32-bit domain optional on Arm64.
Then I think it would be better to pass the domain type when the domain is
created (IOW add an extra flags to XEN_DOMCTL_createdomain).
On 11.09.2025 09:54, Penny, Zheng wrote:
>> -Original Message-
>> From: Penny, Zheng
>> Sent: Thursday, September 11, 2025 3:16 PM
>>
>>> -Original Message-
>>> From: Jan Beulich
>>> Sent: Wednesday, September 10, 2025 10:09 PM
>>>
>>> On 10.09.2025 09:38, Penny Zheng wrote:
-
On 11.09.25 09:48, Peter Zijlstra wrote:
On Thu, Sep 11, 2025 at 08:34:19AM +0200, Juergen Gross wrote:
Some cleanups and reorg of paravirt code and headers:
- The first 2 patches should be not controversial at all, as they
remove just some no longer needed #include and struct forward
dec
On 9/11/25 12:23 AM, Andrew Cooper wrote:
Also state the RISC-V baseline now it's been set, as it's the reason why
RISC-V Bullseye got dropped.
Signed-off-by: Andrew Cooper
LGTM: Acked-by: Oleksii Kurochko
Thanks.
~ Oleksii
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julie
On Thu, Sep 11, 2025 at 08:34:19AM +0200, Juergen Gross wrote:
> Some cleanups and reorg of paravirt code and headers:
>
> - The first 2 patches should be not controversial at all, as they
> remove just some no longer needed #include and struct forward
> declarations.
>
> - The 3rd patch is r
On 10.09.2025 19:29, Alejandro Vallejo wrote:
> On Wed Sep 10, 2025 at 7:01 PM CEST, Alejandro Vallejo wrote:
>> On Wed Sep 10, 2025 at 5:31 PM CEST, Jan Beulich wrote:
>>> On 10.09.2025 17:16, Alejandro Vallejo wrote:
On Wed Sep 10, 2025 at 5:02 PM CEST, Jan Beulich wrote:
> On 10.09.2025
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Wednesday, September 10, 2025 10:09 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Roger Pau Monné ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v2 03/26] xen/x86: consolidate vram tracking support
>
> On 1
On Wed, 10 Sep 2025, Penny Zheng wrote:
> Function domain_set_node_affinity() is responsible for
> XEN_DOMCTL_setnodeaffinity domctl-op, and shall be wrapped with
> CONFIG_MGMT_HYPERCALLS
> Wrap XEN_DOMCTL_setnodeaffinity-case and xenctl_bitmap_to_nodemask()
> transiently with CONFIG_MGMT_HYPERCALL
Wrap domctl hypercall def and domctl.o with CONFIG_MGMT_HYPERCALLS,
and remove all #ifdef CONFIG_MGMT_HYPERCALLS wrappings in common/domctl.c
With MGMT_HYPERCALLS=n, we need to provide stub for
domctl_lock_{acquire,release}(), as it may be invoked by hvm_set_param().
Signed-off-by: Penny Zheng
--
90 matches
Mail list logo
