On 25.07.25 04:28, Jason Andryuk wrote:
Add a helper to lookup the event channel for a domid. This hides some
of the differences between dom0 and stubdom xenstored.
It highlights the different meanings between get_xenbus_evtchn() in a
stubdom, where it looks up dom0's event channel, and dom0, w
On 25.07.25 04:28, Jason Andryuk wrote:
Make introduce_domain() use an event channel from the the xenstore page.
It is only used if non-zero. Otherwise the passed in event channel port
is used.
The is useful for a xenstored stubdom to configure domains autonomously.
Signed-off-by: Jason Andryu
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Friday, July 25, 2025 1:38 PM
> To: Stefano Stabellini
> Cc: Penny, Zheng ; Huang, Ray
> ; Julien Grall ; Bertrand Marquis
> ; Orzel, Michal ;
> Volodymyr Babchuk ; Andrew Cooper
> ; Anthony PERARD ;
> Roger Pau Monné ; Daniel P.
In order to fix CI error of a randconfig picking both PV_SHIM_EXCLUSIVE=y and
HVM=y results in hvm.c being built, but domctl.c not being built, which leaves
a few functions, like domctl_lock_acquire/release() undefined, causing linking
to fail.
To fix that, we intend to move domctl.o out of the PV_
On 25.07.2025 08:15, Jiqian Chen wrote:
> Jiqian Chen (11):
> xen: Introduce CONFIG_PLATFORM_OP
> xen/xsm: Wrap around xsm_platform_op with CONFIG_PLATFORM_OP
> xen/platform_op: Wrap around XENPF_microcode_update(2)
> xen/platform_op: Wrap around XENPF_firmware_info
> xen/platform_op: Wra
core_parking_helper() and get_cur_idle_nums() are only used for
XENPF_core_parking, so wrap them.
Signed-off-by: Jiqian Chen
---
cc: Andrew Cooper
cc: Anthony PERARD
cc: Michal Orzel
cc: Jan Beulich
cc: Julien Grall
cc: "Roger Pau Monné"
cc: Stefano Stabellini
---
xen/common/core_parking.
Wrap platform_op hypercall definition and platform_hypercall.o of arm and
x86 with CONFIG_PLATFORM_OP, and since PV_SHIM_EXCLUSIVE needs sorting in
the future, move them out of PV_SHIM_EXCLUSIVE condition at the same time.
And need to make PLATFORM_OP with help info. It shall at least provide
"# C
On 24.07.2025 18:23, Andrew Cooper wrote:
> Right now, domains start with no colouring information and depend on a
> XEN_DOMCTL_set_llc_colors(nr=0) hypercall in order to get default colours.
>
> This in turn forces the toolstack to make a hypercall for all VMs even those
> without colouring confi
Hi,
> On 24 Jul 2025, at 02:59, dm...@proton.me wrote:
>
> On Wed, Jul 23, 2025 at 06:54:19PM -0400, Stewart Hildebrand wrote:
>> In arm_smmu_deassign_dev(), the return value from to_smmu_domain() is
>> NULL-checked. However, the implementation of to_smmu_domain() is a
>> container_of lookup, so
Wrap around call stack functions of XENPF_mem_hotadd:
memory_add
mem_hotadd_check
valid_numa_range
extend_frame_table
setup_frametable_chunk
setup_m2p_table
m2p_mapped
setup_compat_m2p_table
allo
Since xsm_resource_plug_core and xsm_resource_unplug_core are only
used for arch/x86/platform_hypercall.c and arch/sysctl.c, so wrap
around them with CONFIG_SYSCTL and CONFIG_PLATFORM_OP.
Signed-off-by: Jiqian Chen
---
cc: "Daniel P. Smith"
---
xen/include/xsm/xsm.h | 8
xen/xsm/dummy.
efi_get_info() is only used for XEN_FW_EFI_INFO of XENPF_firmware_info,
so wrap it.
And wrap its compat function efi_compat_get_info().
Signed-off-by: Jiqian Chen
---
cc: "Daniel P. Smith"
cc: "Marek Marczykowski-Górecki"
cc: Jan Beulich
---
xen/common/efi/common-stub.c | 4
xen/common/e
Wrap around the call stack functions of XENPF_set_processor_pminfo:
set_px_pminfo
print_PCT
print_PSS
print_PSD
print_PPC
check_psd_pminfo
cpufreq_limit_change
cpufreq_cpu_init
set_cx_pminfo
copy_from_compat_state
set_cx
Hi all,
This is a continuation of the disabling some hypercalls handling code series.
https://lore.kernel.org/xen-devel/20250704092952.822578-1-penny.zh...@amd.com/
It can be beneficial for some dom0less systems to further reduce Xen footprint
via disabling some hypercalls handling code, which may
As function xsm_platform_op() is solely invoked in platform_hypercall.c,
it needs to be wrapped around with CONFIG_PLATFORM_OP.
Signed-off-by: Jiqian Chen
---
cc: "Daniel P. Smith"
---
xen/include/xsm/xsm.h | 4
xen/xsm/dummy.c | 3 +++
xen/xsm/flask/hooks.c | 5 +
3 files change
Wrap call stack functions of XENPF_enter_acpi_sleep:
acpi_enter_sleep
enter_state_helper
enter_state
freeze_domains
scheduler_disable
schedule_dummy
disable_nonboot_cpus
efi_runtime_call() is only used for XENPF_efi_runtime_call, wrap
it and its compat function and its calling functions:
efi_compat_runtime_call()
gwstrlen()
cast_time()
cast_guid()
Signed-off-by: Jiqian Chen
---
cc: "Daniel P. Smith"
cc: "Marek Marczykowski-Górecki"
cc: Jan Beulich
---
xen/com
ucode_update_hcall() is only used for XENPF_microcode_update and
XENPF_microcode_update2, so wrap it and its call stack functions:
ucode_update_hcall
ucode_update_hcall_cont
do_microcode_update
control_thread_fn
microco
Introduce a new Kconfig CONFIG_PLATFORM_OP, which shall only be disabled
on some dom0less systems or PV shim on x86, to reduce Xen footprint.
The consequence of introducing "CONFIG_PLATFORM_OP=y" in .config file
generated from pvshim_defconfig is transient, which will be adjusted in
the final patc
> On 24 Jul 2025, at 03:00, dm...@proton.me wrote:
>
> On Wed, Jul 23, 2025 at 06:54:20PM -0400, Stewart Hildebrand wrote:
>> When attempting to xl pci-assignable-remove a PCI device, we encounter:
>>
>> $ xl pci-assignable-remove 00:01.0
>> (XEN) SMMUv3: : not attached to domain 32753
>> (XE
Hi,
> On 24 Jul 2025, at 00:54, Stewart Hildebrand
> wrote:
>
> In arm_smmu_deassign_dev(), the return value from to_smmu_domain() is
> NULL-checked. However, the implementation of to_smmu_domain() is a
> container_of lookup, so the return value is unlikely to ever be NULL. In
> case of a NULL
On 24.07.2025 18:23, Andrew Cooper wrote:
> domain_destroy() is the wrong position to be freeing colouring information.
>
> The comment in context identifies how domain_destroy() can be called multiple
> times on the same domain, leading to a double free of d->llc_colors as it's
> the wrong side o
On 24.07.2025 18:23, Andrew Cooper wrote:
> --- a/xen/common/llc-coloring.c
> +++ b/xen/common/llc-coloring.c
> @@ -309,11 +309,8 @@ int domain_set_llc_colors(struct domain *d,
>
> void domain_llc_coloring_free(struct domain *d)
> {
> -if ( !llc_coloring_enabled || d->llc_colors == default_
On 25.07.2025 03:21, Stefano Stabellini wrote:
> On Thu, 24 Jul 2025, Jan Beulich wrote:
>> On 23.07.2025 22:30, Stefano Stabellini wrote:
>>> On Wed, 23 Jul 2025, Jan Beulich wrote:
On 23.07.2025 02:46, Stefano Stabellini wrote:
> On Tue, 22 Jul 2025, Jan Beulich wrote:
>> On 22.07.20
On 24.07.2025 18:48, Mykola Kvach wrote:
> On Thu, Jul 24, 2025 at 3:13 PM Jan Beulich wrote:
>>
>> On 24.07.2025 13:41, Mykola Kvach wrote:
>>> Hi all,
>>>
>>> On Tue, Jun 24, 2025 at 12:32 PM Mykola Kvach
>>> wrote:
On Tue, Jun 24, 2025 at 11:32 AM Jan Beulich wrote:
>
> On
On 24.07.2025 17:59, Aidan Allen wrote:
> On Thu, Jul 24, 2025 at 12:52 PM Jan Beulich wrote:
>> On 24.07.2025 13:40, Aidan Allen wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -253,6 +253,10 @@ void dump_pageframe_info(struct domain *d)
>>> page->cou
On 25.07.25 00:48, Jason Andryuk wrote:
On 2025-07-22 10:06, Juergen Gross wrote:
Add per domain server features, which are initialized by the supported
features at domain introduction, or by live update from the migration
stream. This requires to add the DOMAIN_DATA record to the migration
st
On 2025/7/24 22:28, Roger Pau Monné wrote:
> On Thu, Jul 24, 2025 at 01:50:00PM +0800, Jiqian Chen wrote:
>> Refactor REGISTER_VPCI_INIT to contain more capability specific
>> information, this will benefit further follow-on changes to hide
>> capability when initialization fails.
>>
>> What's more
On Thu, Jul 17, 2025 at 01:52:05PM +0200, David Hildenbrand wrote:
>Let's clean it all further up.
>
>No functional change intended.
>
>Reviewed-by: Oscar Salvador
>Reviewed-by: Alistair Popple
>Signed-off-by: David Hildenbrand
Reviewed-by: Wei Yang
--
Wei Yang
Help you, Help me
On 2025/7/24 23:59, Roger Pau Monné wrote:
> On Thu, Jul 24, 2025 at 01:50:06PM +0800, Jiqian Chen wrote:
>> When init_msix() fails, current logic return fail and free MSIX-related
>> resources in vpci_deassign_device(). But the previous new changes will
>> hide MSIX capability and return success,
On Thu, Jul 17, 2025 at 01:52:04PM +0200, David Hildenbrand wrote:
>Let's clean it all further up.
>
>No functional change intended.
>
>Reviewed-by: Oscar Salvador
>Reviewed-by: Alistair Popple
>Signed-off-by: David Hildenbrand
Reviewed-by: Wei Yang
--
Wei Yang
Help you, Help me
Rename the helper that access store_domid accordingly.
While doing this, rename the is_store_domain variable.
No functional change.
Signed-off-by: Jason Andryuk
---
tools/xenstored/core.h | 2 +-
tools/xenstored/domain.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git
Replace dom0_init() with init_domains() which uses libxenmanage to
iterate through all existing domains, storing them in a list. The xenstore
domain is introduced first, and then all the other domains are
introduced. The xenstore domain needs to be introduced first to setup
structures needed for
posix.c and minios.c implement the same named functions serving slightly
different purposes.
For xenbus_map()
posix.c maps the local /dev/xen/xsd_kva
minios.c maps dom0 via grant and there is open coding for stub_domid in
map_interface.
Change xenbus_map() to map the local domain's interface. Th
Update get_implicit_path to return the correct value for a non-dom0
xenstored domain.
Signed-off-by: Jason Andryuk
---
tools/xenstored/domain.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c
index f1527a6db7..ae59b6e6
The dom0_domid variable is misnamed and conflates purposes. If we have
xenstored running in a Linux domain that is not dom0, this variable
controls the lookup of /proc/xen/xsd_kva and the event channel.
One implication of this change is that the xenstore domain is not
privileged by virtue of cons
Usually, priv_domid == dom0_domid == 0, and that is what is expected.
If we rename s/dom0_domid/store_domid/, it seems more likely we want to
actually have the priv_domid as the owner.
That leads to follow on changes to ensure that the priv_domid is created
first.
Signed-off-by: Jason Andryuk
--
Make introduce_domain() use an event channel from the the xenstore page.
It is only used if non-zero. Otherwise the passed in event channel port
is used.
The is useful for a xenstored stubdom to configure domains autonomously.
Signed-off-by: Jason Andryuk
---
v2:
Remove iface_port variable.
---
Expose a domain's capabilities - control, hardware or xenstore - through
stable get domain state hypercall.
The xenstore domain can use this information to assign appropriate
permissions on connections.
Repurpose the 16bit pad field for this purpose.
Signed-off-by: Jason Andryuk
Reviewed-by: Ju
Include the event channel in struct xenstore_domain_interface. This way
the toolstack or xen can communicate the event channel to xenstored in
memory xenstored already needs to access.
xenstored maps the grant with the well known GNTTAB_RESERVED_XENSTORE
index, so no further information is needed
Add a helper to lookup the event channel for a domid. This hides some
of the differences between dom0 and stubdom xenstored.
It highlights the different meanings between get_xenbus_evtchn() in a
stubdom, where it looks up dom0's event channel, and dom0, where it
looks up the local event channel.
Write the associated event channel into the xenstore page so xenstored
can read it. xenstored can map the grant by the reserved grant table
entry, and then read out the event channel and bind it. This eliminates
the need for an additional mechanism to discover the event channel.
Signed-off-by: J
Add an additional "caps" argument to the libxenmanage functions to
obtain a domains capabilities - control, hardware, and xenstore.
Update the xenstored callers at the same time.
Signed-off-by: Jason Andryuk
Reviewed-by: Juergen Gross
---
v2:
Add Juergen's R-b
---
tools/include/xenmanage.h | 1
This is a subset of patches focusing on xenstored changes from my split
hardware control domain series.
It should address the stubdom breakage from the previous series. Due to
a lack of x86 test systems, I haven't tested with a stubdom yet :(
I'll try to remedy that.
"tools/xenstored: Use priv_d
On 7/24/25 18:33, Anderson Choi wrote:
> ARINC653 specification requires partition scheduling to be deterministic
> and periodic over time.
>
> However, the use of current timestamp (now) as the baseline to calculate
> next_major_frame and next_switch_time introduces a delay in the start of
> majo
On Thu, 24 Jul 2025, Jan Beulich wrote:
> On 23.07.2025 22:30, Stefano Stabellini wrote:
> > On Wed, 23 Jul 2025, Jan Beulich wrote:
> >> On 23.07.2025 02:46, Stefano Stabellini wrote:
> >>> On Tue, 22 Jul 2025, Jan Beulich wrote:
> On 22.07.2025 07:04, Penny Zheng wrote:
> > Function getd
On Thu, 24 Jul 2025, Dmytro Prokopchuk1 wrote:
> These functions never return to their caller,
> causing a violation of MISRA C Rule 2.1:
> "A project shall not contain unreachable code".
> Add the `noreturn' attribute to fix this.
>
> No functional changes.
>
> Signed-off-by: Dmytro Prokopchuk
On Fri, 6 Jun 2025, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Add CONSOLE_PREFIX symbol to keep the prefix of the hypervisor's diagnostic
> messages.
>
> No functional change.
>
> Signed-off-by: Denis Mukhin
Reviewed-by: Stefano Stabellini
> ---
> Changes since v2:
> - n/a
> ---
> x
On 2025-07-22 10:06, Juergen Gross wrote:
Add a guest config parameter "xenstore_feature_mask" allowing to limit
the Xenstore features the guest can see and use. This can be needed in
order to allow migrating a guest to a host running a Xenstore version
providing less features than the source hos
On 2025-07-22 10:06, Juergen Gross wrote:
Add the Xenstore feature value to the output of "xl info" in order to
prepare for a future capability to limit Xenstore features visible by
a guest.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
On 2025-07-22 10:06, Juergen Gross wrote:
Add support for XS_SET_FEATURE and XS_GET_FEATURE to xenstored.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
On 2025-07-22 10:06, Juergen Gross wrote:
Add per domain server features, which are initialized by the supported
features at domain introduction, or by live update from the migration
stream. This requires to add the DOMAIN_DATA record to the migration
stream, but for now it will only contain t
On 2025-07-10 23:51, Penny Zheng wrote:
HWP and amd-cppc-epp are both governor-less driver, so we introduce "hw_auto"
flag to together bypass governor-related print in print_cpufreq_para().
In set_cpufreq_para(), a new helper is introduced to help error out when
cpufreq core intialized in govern
On 2025-07-22 10:06, Juergen Gross wrote:
Add all the missing migration record structures and defines to the
xenstore_state.h header file.
Update the version of the migration stream to "2". In order to allow
receiving version 1 streams, change the version check of the header
to reject only strea
On 2025-07-22 10:06, Juergen Gross wrote:
In order to prepare xenstored supporting migration stream versions
other than 1, add a parameter to the live update command allowing to
specify the version of the migration stream.
This will allow going back from xenstored using version 2 per default
to
On 2025-07-22 10:06, Juergen Gross wrote:
Add functions for getting and setting Xenstore features to libxenstore:
xs_get_features_supported(): return the features supported by the
running Xenstore implementation as defined in xs_wire.h via the
XENSTORE_SERVER_FEATURE_* macros.
xs_get_features_d
These functions never return to their caller,
causing a violation of MISRA C Rule 2.1:
"A project shall not contain unreachable code".
Add the `noreturn' attribute to fix this.
No functional changes.
Signed-off-by: Dmytro Prokopchuk
---
xen/arch/arm/domain.c | 2 +-
xen/arch/arm/setup.c | 2
ARINC653 specification requires partition scheduling to be deterministic
and periodic over time.
However, the use of current timestamp (now) as the baseline to calculate
next_major_frame and next_switch_time introduces a delay in the start of
major frame at every period, which breaks determinism a
On Thu, 24 Jul 2025, Stewart Hildebrand wrote:
> All IOMMU_QUARANTINE_* options are exposed on Arm since 163c6b589879
> ("xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option"). However,
> only NONE and BASIC are implemented in any Arm iommu driver since
> 63919fc4d1ca ("xen/arm: smmuv3: Add PCI
All IOMMU_QUARANTINE_* options are exposed on Arm since 163c6b589879
("xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option"). However,
only NONE and BASIC are implemented in any Arm iommu driver since
63919fc4d1ca ("xen/arm: smmuv3: Add PCI devices support for SMMUv3") and
ca8f6ffeb6e3 ("xen/arm
On Thu, 24 Jul 2025, Andrew Cooper wrote:
> On 24/07/2025 9:37 am, Anthony PERARD wrote:
> > From: Anthony PERARD
> >
> > Signed-off-by: Anthony PERARD
> > ---
> >
> > Notes:
> > The job build-each-commit is a bit faster, and can do about twice as
> > much builds.
> >
> >
>
On Thu, Jul 24, 2025 at 3:13 PM Jan Beulich wrote:
>
> On 24.07.2025 13:41, Mykola Kvach wrote:
> > Hi all,
> >
> > On Tue, Jun 24, 2025 at 12:32 PM Mykola Kvach
> > wrote:
> >>
> >> On Tue, Jun 24, 2025 at 11:32 AM Jan Beulich wrote:
> >>>
> >>> On 24.06.2025 10:29, Mykola Kvach wrote:
>
On Wed, Jul 23, 2025 at 12:37:41PM -0400, Stewart Hildebrand wrote:
> Introduce vPCI BAR mapping task queue. Decouple map operation state from
> general vPCI state: in particular, move the per-BAR rangeset out of
> struct vpci and into the map task struct.
>
> This is preparatory work for further
Hi Anthony,
On Thu, Jul 24, 2025 at 5:01 PM Anthony PERARD wrote:
>
> On Thu, Jul 24, 2025 at 12:40:57PM +0300, Mykola Kvach wrote:
> > From: Mykola Kvach
> >
> > The "xl resume" command was previously excluded from Arm builds because
> > system suspend/resume (e.g., SYSTEM_SUSPEND via vPSCI) wa
Right now, domains start with no colouring information and depend on a
XEN_DOMCTL_set_llc_colors(nr=0) hypercall in order to get default colours.
This in turn forces the toolstack to make a hypercall for all VMs even those
without colouring configured, and to ignore errors if Xen doesn't have
colo
Using:
xfree(__va(__pa(d->llc_colors)));
is an extraordinarily expensive way of writing:
xfree((void *)d->llc_colours);
Combined with the comment indicating that this was intention, the patch should
have been rejected outright.
Correct the type of d->llc_colours by removing the bogus const
Hypercalls are not free; cache colouring is an experimental feature, and
ignoring an -EOPNOTSUPP is bad form.
Now that Xen has been fixed to initialise colouring information correctly for
domains, xc_domain_set_llc_colors() only needs calling for domains with
explicit configuration.
Rearrange the
domain_destroy() is the wrong position to be freeing colouring information.
The comment in context identifies how domain_destroy() can be called multiple
times on the same domain, leading to a double free of d->llc_colors as it's
the wrong side of the atomic_cmpxchg() to be made safe.
Furthermore
Found because XEN_DOMCTL_set_llc_colors failed in XenServer's HostUEFI Secure
Boot environment (which has additional checks on hypercalls). Everything else
came from trying to fix that.
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1946483850
Andrew Cooper (4):
xen/cache-col:
On Thu, Jul 24, 2025 at 12:52 PM Jan Beulich wrote:
>
> On 24.07.2025 13:40, Aidan Allen wrote:
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -253,6 +253,10 @@ void dump_pageframe_info(struct domain *d)
> > page->count_info, page->u.inuse.type_info);
> >
On Thu, Jul 24, 2025 at 01:50:06PM +0800, Jiqian Chen wrote:
> When init_msix() fails, current logic return fail and free MSIX-related
> resources in vpci_deassign_device(). But the previous new changes will
> hide MSIX capability and return success, it can't reach
> vpci_deassign_device() to remov
Hello everyone!
### Background
Unlike the Linux kernel, which has supported extended shared peripheral
interrupts (eSPIs) since 2019 [1], Xen currently lacks support for this
interrupt range. For SoCs with GICv3.1+, this feature may be essential
because critical devices, such as consoles required
To properly deactivate guest interrupts and allow them to be retriggered
after the initial trigger, the LR needs to be updated. The current
implementation ignores interrupts outside the range specified by the mask
0x3FF, which only covers IRQ numbers up to 1023. To enable processing of
eSPI interru
The Dom0 configuration logic in create_dom0() has been updated
to account for extended SPIs when supported by the hardware and
enabled with CONFIG_GICV3_ESPI. These changes ensure the proper
calculation of the maximum number of SPIs and eSPIs available for Dom0.
When eSPIs are supported by the har
On Tue, Jul 15, 2025 at 09:44:02PM +0800, WangYuli wrote:
> There is a spelling mistake of 'notifer' in the comment which
> should be 'notifier'.
>
> Link:
> https://lore.kernel.org/all/b3c019b63c93846f+20250715071245.398846-1-wangy...@uniontech.com/
> Signed-off-by: WangYuli
Reviewed-by: Matth
Introduced appropriate register definitions, helper macros,
and initialization of required GICv3.1 distributor registers
to support eSPI. This type of interrupt is handled in the
same way as regular SPI interrupts, with the following
differences:
1) eSPIs can have up to 1024 interrupts, starting f
Currently, Xen does not support eSPI interrupts, leading
to a data abort when such interrupts are defined in the DTS.
This patch introduces a separate array to initialize up to
1024 interrupt descriptors in the eSPI range and adds the
necessary defines and helper function. These changes lay the
gr
Current checks prevent routing of interrupts from the eSPI range to Xen
or guest domains. The addition of the is_espi condition allows verification
of whether a given index falls within the eSPI range, enabling routing of
such interrupts.
Existing behavior remains unchanged for configurations wher
Implemented support for GICv3.1 extended SPI registers for vGICv3,
allowing the emulation of eSPI-specific behavior for guest domains.
The implementation includes read and write emulation for eSPI-related
registers (e.g., GICD_ISENABLERnE, GICD_IROUTERnE, and others),
following a similar approach t
Currently, many common functions perform the same operations to calculate
GIC register addresses. This patch consolidates the similar code into
a separate helper function to improve maintainability and reduce duplication.
This refactoring also simplifies the implementation of eSPI support in future
The current checks don't allow us to assign or release interrupts
with INTID greater than 1024. This patch adds an additional condition
to check whether the IRQ number is in the eSPI range and allows it to
be assigned to Xen and domains if it is.
Signed-off-by: Leonid Komarianskyi
---
xen/arch/a
This change introduces resource management in the VGIC to handle
extended SPIs introduced in GICv3.1. The pending_irqs and
allocated_irqs arrays are resized to support the required
number of eSPIs, based on what is supported by the hardware and
requested by the guest. A new field, ext_shared_irqs,
The do_IRQ() function is the main handler for processing IRQs.
Currently, due to restrictive checks, it does not process interrupt
numbers greater than 1024. This patch updates the condition to allow
the handling of interrupts from the eSPI range.
Signed-off-by: Leonid Komarianskyi
---
xen/arch/
On Thu, Jul 24, 2025 at 01:50:05PM +0800, Jiqian Chen wrote:
> When init_msi() fails, current logic return fail and free MSI-related
> resources in vpci_deassign_device(). But the previous new changes will
> hide MSI capability and return success, it can't reach
> vpci_deassign_device() to remove r
On Thu, Jul 24, 2025 at 01:50:01PM +0800, Jiqian Chen wrote:
> When vpci fails to initialize a legacy capability of device, it just
> returns an error and vPCI gets disabled for the whole device. That
> most likely renders the device unusable, plus possibly causing issues
> to Xen itself if guest
On 24.07.2025 16:17, Jason Andryuk wrote:
> On 2025-07-24 09:31, Jan Beulich wrote:
>> On 11.07.2025 05:51, Penny Zheng wrote:
>>> In amd-cppc passive mode, it's Xen governor which is responsible for
>>> performance tuning, so governor and CPPC could co-exist. That is, both
>>> governor-info and CP
On 11.07.2025 05:51, Penny Zheng wrote:
> Introduce helper set_amd_cppc_para() and get_amd_cppc_para() to
> SET/GET CPPC-related para for amd-cppc/amd-cppc-epp driver.
>
> In get_cpufreq_cppc()/set_cpufreq_cppc(), we include
> "processor_pminfo[cpuid]->init & XEN_CPPC_INIT" condition check to deal
On Thu, Jul 24, 2025 at 01:50:00PM +0800, Jiqian Chen wrote:
> Refactor REGISTER_VPCI_INIT to contain more capability specific
> information, this will benefit further follow-on changes to hide
> capability when initialization fails.
>
> What's more, change the definition of init_header() since it
Hi All,
On 23.07.25 15:12, Grygorii Strashko wrote:
On 23.07.25 15:02, Julien Grall wrote:
Hi,
On 23/07/2025 12:48, Grygorii Strashko wrote:
On 23.07.25 13:54, Orzel, Michal wrote:
On 23/07/2025 10:06, Julien Grall wrote:
On 23/07/2025 08:58, Grygorii Strashko wrote:
From: Grygorii
On 2025-07-24 09:31, Jan Beulich wrote:
On 11.07.2025 05:51, Penny Zheng wrote:
In amd-cppc passive mode, it's Xen governor which is responsible for
performance tuning, so governor and CPPC could co-exist. That is, both
governor-info and CPPC-info need to be printed together via xenpm tool.
If
On Thu, Jul 24, 2025 at 10:09:43AM +0200, Jan Beulich wrote:
> On 24.07.2025 07:49, Jiqian Chen wrote:
> > Add a new function to emulate extended capability list for dom0,
> > and call it in init_header(). So that it will be easy to hide an
> > extended capability whose initialization fails.
> >
>
On 7/24/25 04:07, Jan Beulich wrote:
> On 23.07.2025 20:13, Stewart Hildebrand wrote:
>> From: Stefano Stabellini
>>
>> Up until f9f6b22abf1d "xen/arm: Map ITS doorbell register to IOMMU page
>> tables" the only caller of iommu_map on ARM was grant_table.c which has
>> a specific usage model and r
On 24.07.2025 16:09, Roger Pau Monné wrote:
> On Thu, Jul 24, 2025 at 10:18:37AM +0200, Jan Beulich wrote:
>> Use the more "modern" form, thus doing away with effectively open-coding
>> xmalloc_array() at the same time. While there is a difference in
>> generated code, as xmalloc_bytes() forces SMP
On 7/23/25 17:54, Jan Beulich wrote:
> On 23.07.2025 17:39, Yann Sionneau wrote:
>> On 7/23/25 16:18, Jan Beulich wrote:
>>> On 23.07.2025 15:56, Yann Sionneau wrote:
xen.efi PE does not boot when loaded from shim or some patched
downstream grub2.
What happens is the bootloader
On Thu, Jul 24, 2025 at 10:18:37AM +0200, Jan Beulich wrote:
> Use the more "modern" form, thus doing away with effectively open-coding
> xmalloc_array() at the same time. While there is a difference in
> generated code, as xmalloc_bytes() forces SMP_CACHE_BYTES alignment, if
> code really cared ab
On 11.07.2025 05:51, Penny Zheng wrote:
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -968,3 +968,9 @@ bool cpufreq_in_cppc_passive_mode(unsigned int cpuid)
> return processor_pminfo[cpuid]->init & XEN_CPPC_INIT &&
> cpufreq_driver.target;
> }
>
xen.efi PE does not boot when loaded from shim or some patched
downstream grub2.
What happens is the bootloader would honour the MEM_DISCARDABLE
flag of the .reloc section meaning it would not load its content
into memory.
But Xen is parsing the .reloc section content twice at boot:
* https://eli
On Thu, Jul 24, 2025 at 12:40:57PM +0300, Mykola Kvach wrote:
> From: Mykola Kvach
>
> The "xl resume" command was previously excluded from Arm builds because
> system suspend/resume (e.g., SYSTEM_SUSPEND via vPSCI) was not
> implemented. On x86, this command is used for ACPI S3 suspend/resume.
>
On 11.07.2025 05:51, Penny Zheng wrote:
> --- a/xen/drivers/acpi/pm-op.c
> +++ b/xen/drivers/acpi/pm-op.c
> @@ -152,7 +152,15 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
> else
> strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
>
> -ret = get_
Hi Julien, Andrew Cooper
Thanks for your comment.
On 23.07.25 14:09, Julien Grall wrote:
Hi,
On 23/07/2025 11:19, Grygorii Strashko wrote:
On 23.07.25 12:16, Julien Grall wrote:
On 23/07/2025 08:58, Grygorii Strashko wrote:
From: Grygorii Strashko
Move vcpu_switch_to_aarch64_mode() in ar
1 - 100 of 149 matches
Mail list logo
