On 06.03.25 23:03, Jason Andryuk wrote:
With split hardware and control domains, each domain should be
privileged with respect to xenstore. When adding domains to xenstore,
look at their privilege and add them to xenstored as appropriate.
dom0_domid is used for the hardware domain, and priv_domi
All local APIC drivers use physical destination and fixed delivery modes,
remove the fields from the genapic struct and simplify the logic.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/genapic/bigsmp.c | 2 --
xen/arch/x86/genapic/default.c | 2 --
x
On Fri, 7 Mar 2025, Julien Grall wrote:
> > What exactly do you mean by imposing with respect to the iommu? Require
> > one, or mirror the dom0 code and set it for the hwdom?
> >
> > if ( iommu_enabled )
> > dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
>
> I mean requires one. Without i
On Fri, 7 Mar 2025, Julien Grall wrote:
> > init-dom0less only initializes non- introduced domains, so hwdom doesn't get
> > its "domid" xenstore node populated. That leads to other errors.
> > > So I think with Denis's patch, this isn't strictly needed. It does help
> > existing toolstack code w
On Fri, 7 Mar 2025, Jason Andryuk wrote:
> On 2025-03-07 16:24, Julien Grall wrote:
> > Hi,
> >
> > On 06/03/2025 22:03, Jason Andryuk wrote:
> > > With a split hardware and control domain, the control domain may still
> > > want and xenstore access. Currently this relies on init-dom0less to
> >
On Fri, 7 Mar 2025, Jason Andryuk wrote:
> On 2025-03-07 16:01, Julien Grall wrote:
> > Hi Jason,
> >
> > On 07/03/2025 16:03, Jason Andryuk wrote:
> > > On 2025-03-07 03:31, Julien Grall wrote:
> > > > Hi,
> > > >
> > > > On 06/03/2025 22:03, Jason Andryuk wrote:
> > > > > Assign domid 0 to the
It is valid for a PCI device to not have a legacy IRQ. In that case, do
not print an error to keep the lgs clean.
This relies on pciback being updated to return -ENOENT for a missing
GSI.
Fixes: b93e5981d258 ("tools: Add new function to get gsi from dev")
Signed-off-by: Jason Andryuk
---
v2:
Us
A PCI device may not have a legacy IRQ assigned. This series allows
passthrough of such a device to a guest.
It relies on a Linux change to xen-pciback to also handle missing legacy
IRQs:
https://lore.kernel.org/xen-devel/20250226200134.29759-1-jason.andr...@amd.com/T/#u
Jason Andryuk (2):
too
A PCI device may not have a legacy IRQ. In that case, we don't need to
do anything, so don't fail in libxl__arch_hvm_map_gsi() and
libxl__arch_hvm_unmap_gsi().
Requires an updated pciback to return -ENOENT.
Fixes: f97f885c7198 ("tools: Add new function to do PIRQ (un)map on PVH dom0")
Signed-off
On 2025-03-07 16:21, Julien Grall wrote:
Hi Jason,
On 07/03/2025 17:58, Jason Andryuk wrote:
On 2025-03-07 04:01, Julien Grall wrote:
Hi,
On 06/03/2025 22:03, Jason Andryuk wrote:
Add capabilities property to dom0less to allow building a
disaggregated system.
Introduce bootfdt.h to contain
Hi Jason,
On 07/03/2025 16:03, Jason Andryuk wrote:
On 2025-03-07 03:31, Julien Grall wrote:
Hi,
On 06/03/2025 22:03, Jason Andryuk wrote:
Assign domid 0 to the hwdom. Normally, dom0less does not use domid 0.
A few years ago, we went to great length to avoid making the
assumption that the
On 2025-03-07 16:24, Julien Grall wrote:
Hi,
On 06/03/2025 22:03, Jason Andryuk wrote:
With a split hardware and control domain, the control domain may still
want and xenstore access. Currently this relies on init-dom0less to
seed the grants. This is problematic since we don't want hardware
d
On 2025-03-07 16:01, Julien Grall wrote:
Hi Jason,
On 07/03/2025 16:03, Jason Andryuk wrote:
On 2025-03-07 03:31, Julien Grall wrote:
Hi,
On 06/03/2025 22:03, Jason Andryuk wrote:
Assign domid 0 to the hwdom. Normally, dom0less does not use domid 0.
A few years ago, we went to great lengt
On 2025-03-07 19:30, Andrew Cooper wrote:
On 07/03/2025 6:22 pm, Nicola Vetrini wrote:
On 2025-03-07 18:54, Andrew Cooper wrote:
and these too, but will require MISRA adjustments:
* _Generic() to make properly const-preserving wrappers
Perhaps stating something that is already well-known, b
Hi,
On 06/03/2025 22:03, Jason Andryuk wrote:
With a split hardware and control domain, the control domain may still
want and xenstore access. Currently this relies on init-dom0less to
seed the grants. This is problematic since we don't want hardware
domain to be able to map the control domain
Hi Jason,
On 07/03/2025 17:58, Jason Andryuk wrote:
On 2025-03-07 04:01, Julien Grall wrote:
Hi,
On 06/03/2025 22:03, Jason Andryuk wrote:
Add capabilities property to dom0less to allow building a
disaggregated system.
Introduce bootfdt.h to contain these constants.
When using the hardware
Hi,
On 07/03/2025 17:54, Andrew Cooper wrote:
GCC 4.1.2 is from 2007, and Binutils 2.16 is a similar vintage. Clang 3.5 is
from 2014. Supporting toolchains this old is a massive development and
testing burden.
Set a minimum baseline of GCC 5.1 across the board, along with Binutils 2.25
which
On 06.03.25 11:27, Jan Beulich wrote:
On 06.03.2025 09:21, Juergen Gross wrote:
The GET_FEATURE, SET_FEATURE, GET_QUOTA and SET_QUOTA Xenstore commands
are defined in docs/misc/xenstore.txt, but they are missing in
xs_wire.h.
Add the missing commands to xs_wire.h
Signed-off-by: Juergen Gross
On 2025-03-07 04:01, Julien Grall wrote:
Hi,
On 06/03/2025 22:03, Jason Andryuk wrote:
Add capabilities property to dom0less to allow building a
disaggregated system.
Introduce bootfdt.h to contain these constants.
When using the hardware or xenstore capabilities, adjust the grant and
event c
On 2025-03-06 20:59, Stefano Stabellini wrote:
On Thu, 6 Mar 2025, Jason Andryuk wrote:
@@ -697,7 +703,7 @@ static int __init alloc_xenstore_evtchn(struct domain *d)
int rc;
alloc.dom = d->domain_id;
-alloc.remote_dom = hardware_domain->domain_id;
+alloc.remote_dom = xs
On 2025-03-06 20:47, Stefano Stabellini wrote:
On Thu, 6 Mar 2025, Jason Andryuk wrote:
With a split hardware and control domain, the control domain may still
want and xenstore access. Currently this relies on init-dom0less to
seed the grants. This is problematic since we don't want hardware
d
On 07/03/2025 6:22 pm, Nicola Vetrini wrote:
> On 2025-03-07 18:54, Andrew Cooper wrote:
>> and these too, but will require MISRA adjustments:
>>
>> * _Generic() to make properly const-preserving wrappers
>
> Perhaps stating something that is already well-known, but this
> effectively means moving
On 2025-03-07 18:54, Andrew Cooper wrote:
GCC 4.1.2 is from 2007, and Binutils 2.16 is a similar vintage. Clang
3.5 is
from 2014. Supporting toolchains this old is a massive development and
testing burden.
Set a minimum baseline of GCC 5.1 across the board, along with Binutils
2.25
which is
GCC 4.1.2 is from 2007, and Binutils 2.16 is a similar vintage. Clang 3.5 is
from 2014. Supporting toolchains this old is a massive development and
testing burden.
Set a minimum baseline of GCC 5.1 across the board, along with Binutils 2.25
which is the same age. These were chosen *3 years ago*
On 2025-03-07 11:40, Jason Andryuk wrote:
On 2025-03-06 20:40, Stefano Stabellini wrote:
On Thu, 6 Mar 2025, Jason Andryuk wrote:
diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-
build.c
index 5a7871939b..068bf99294 100644
--- a/xen/arch/arm/dom0less-build.c
+++ b/xen/arch
As soon as the the domain is in the domlist, it can be queried via various
means, ahead of being fully constructed. Ensure it the UUID give by the
toolstack is in place ahead of this.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Ro
On Fri, Mar 07, 2025 at 01:33:42PM +, Andrew Cooper wrote:
> A few blank lines go a very long way.
>
> Signed-off-by: Andrew Cooper
Acked-by: Anthony PERARD
Thanks,
--
Anthony Perard | Vates XCP-ng Developer
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech
On 2025-03-06 20:40, Stefano Stabellini wrote:
On Thu, 6 Mar 2025, Jason Andryuk wrote:
Add capabilities property to dom0less to allow building a
disaggregated system.
Introduce bootfdt.h to contain these constants.
When using the hardware or xenstore capabilities, adjust the grant and
event c
On Thu, Feb 06, 2025 at 08:49:15PM +0100, Edgar E. Iglesias wrote:
> From: Stefano Stabellini
>
> On IOREQ_TYPE_INVALIDATE we need to invalidate the mapcache for regular
> mappings. Since recently we started reusing the mapcache also to keep
> track of grants mappings. However, there is no need t
On 07/03/2025 2:55 pm, Jason Andryuk wrote:
> On 2025-03-06 17:39, Andrew Cooper wrote:
>> Second, you've created a case where we can make multiple hardware
>> domains, yet it is very much a singleton object from Xen's point of
>> view.
>
> hardware_domain still remains the check for is_hardware_do
On 2025-03-07 03:31, Julien Grall wrote:
Hi,
On 06/03/2025 22:03, Jason Andryuk wrote:
Assign domid 0 to the hwdom. Normally, dom0less does not use domid 0.
A few years ago, we went to great length to avoid making the assumption
that the hardware domain is domid 0. See all the calls to
"is
Fixes: bd9bda50553b ("automation: drop debian:11-riscv64 container")
Signed-off-by: Andrew Cooper
---
CC: Oleksii Kurochko
CC: Stefano Stabellini
---
automation/build/debian/11-riscv64.dockerfile | 33 ---
1 file changed, 33 deletions(-)
delete mode 100644 automation/build/debi
Users need to set "cpufreq=amd-cppc" in xen cmdline to enable
amd-cppc driver, which selects ACPI Collaborative Performance
and Power Control (CPPC) on supported AMD hardware to provide a
finer grained frequency control mechanism.
`verbose` option can also be included to support verbose print.
Whe
On 2025-03-06 17:39, Andrew Cooper wrote:
On 06/03/2025 10:03 pm, Jason Andryuk wrote:
From: "Daniel P. Smith"
Add and use a new internal create domain flag to specify the hardware
domain. This removes the hardcoding of domid 0 as the hardware domain.
This allows more flexibility with domain
On 2025-03-06 20:32, Stefano Stabellini wrote:
On Thu, 6 Mar 2025, Jason Andryuk wrote:
Assign domid 0 to the hwdom. Normally, dom0less does not use domid 0.
This fixes using the Xen console which assumes domid 0 to use the
hypercall interface.
Signed-off-by: Jason Andryuk
I hope there is
Hi,
after all discussions on this thread and Xen-devel, can we agree
that this patch is good as it is and can be merged upstream?
Just to make it clear, it was already acked.
Regards,
Frediano
On Fri, Feb 28, 2025 at 12:37 PM Roger Pau Monné wrote:
>
> On Thu, Feb 27, 2025 at 03:41:54PM +0
On Tue, Feb 18, 2025 at 03:23:25PM +0100, Thomas Zimmermann wrote:
> Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer
> scanline pitch and allocation size. Implementations of struct
> drm_driver.dumb_create can call the new helper for their size
> computations.
>
> There is current
On Fri, Mar 07, 2025 at 09:42:25AM +0100, Simona Vetter wrote:
> On Tue, Feb 18, 2025 at 03:23:25PM +0100, Thomas Zimmermann wrote:
> > Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer
> > scanline pitch and allocation size. Implementations of struct
> > drm_driver.dumb_create can c
When a watchdog fires, the domain is crashed and can't dump any state.
Xen allows a domain to have two separate watchdogs. Therefore, for a
domain running multiple watchdogs (e.g. one based around network, one
for disk), it is important for diagnostics to know which watchdog
fired.
As the printk
Temp commit to update imagebuilder repo for domain capabilities.
Signed-off-by: Jason Andryuk
---
automation/scripts/qemu-smoke-dom0less-arm64.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/automation/scripts/qemu-smoke-dom0less-arm64.sh
b/automation/scripts/qemu-smoke-d
amd-cppc is the AMD CPU performance scaling driver that introduces a
new CPU frequency control mechanism firstly on AMD Zen based CPU series.
The new mechanism is based on Collaborative Processor Performance
Control (CPPC) which is a finer grain frequency management
than legacy ACPI hardware P-Stat
A few blank lines go a very long way.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Juergen Gross
---
tools/libs/uselibs.mk | 15 +++
1 file changed, 15 insertions(+)
diff --git a/tools/libs/uselibs.mk b/tools/libs/uselibs.mk
index c0a234cfec84..3c88e78c10cd 100644
--- a
On 07.03.2025 12:49, Andrew Cooper wrote:
> It has been discovered that VIRQ_ARGO is a 3rd type of VIRQ. Also, recent
> work has prevented global VIRQs from being stolen from the owning domain.
>
> Rewrite the description of VIRQ classifications. Drop the (DOM0) comment from
> the global VIRQs;
On 06.03.2025 17:13, Juergen Gross wrote:
> Some use cases of get_global_virq_handler() didn't account for the
> case of running without hardware domain.
>
> Fix that by testing get_global_virq_handler() returning NULL where
> needed (e.g. when directly dereferencing the result).
>
> Fixes: 98082
On 07.03.2025 00:35, Andrew Cooper wrote:
> We've already scanned features by the time init_e820() is called. Remove the
> cpuid() calls.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
> Backporting. Not sure it's worth backporing, but it is safe (just) to
> backport past commit 3
On 07/03/2025 12:01 pm, Jan Beulich wrote:
> On 07.03.2025 12:50, Oleksii Kurochko wrote:
>> On 3/6/25 9:19 PM, Andrew Cooper wrote:
>>> On 05/03/2025 7:34 am, Jan Beulich wrote:
I was actually hoping to eliminate BITS_PER_LONG at some point, in favor
of using sizeof(long) * BITS_PER_BYTE
On 07.03.2025 12:23, Luca Fancellu wrote:
> +
> +static inline int iommu_domain_init(struct domain *d, unsigned int opts)
> +{
> +/*
> + * Return as the real iommu_domain_init() would: Success when
> + * !is_iommu_enabled(), following from !iommu_enabled when
>>
On 07.03.2025 12:50, Oleksii Kurochko wrote:
> On 3/6/25 9:19 PM, Andrew Cooper wrote:
>> On 05/03/2025 7:34 am, Jan Beulich wrote:
>>> I was actually hoping to eliminate BITS_PER_LONG at some point, in favor
>>> of using sizeof(long) * BITS_PER_BYTE. (Surely in common code we could
>>> retain a sh
It has been discovered that VIRQ_ARGO is a 3rd type of VIRQ. Also, recent
work has prevented global VIRQs from being stolen from the owning domain.
Rewrite the description of VIRQ classifications. Drop the (DOM0) comment from
the global VIRQs; it's not been true for a long time.
Signed-off-by:
On 3/4/25 1:09 PM, Milan Đokić wrote:
diff --git a/xen/arch/riscv/arch.mk b/xen/arch/riscv/arch.mk
index 17827c302c..f4098f5b5e 100644
--- a/xen/arch/riscv/arch.mk
+++ b/xen/arch/riscv/arch.mk
@@ -23,13 +23,17 @@ $(eval $(1) := \
$(call as-insn,$(CC) $(riscv-generic-flags)_$(1),$(value $(1)-i
On 3/6/25 9:19 PM, Andrew Cooper wrote:
On 05/03/2025 7:34 am, Jan Beulich wrote:
On 28.02.2025 17:24, Andrew Cooper wrote:
On 27/02/2025 8:11 am, Jan Beulich wrote:
On 26.02.2025 18:20, Andrew Cooper wrote:
--- a/xen/arch/riscv/include/asm/bitops.h
+++ b/xen/arch/riscv/include/asm/bitops.h
Hi Jan,
+
+static inline int iommu_domain_init(struct domain *d, unsigned int opts)
+{
+/*
+ * Return as the real iommu_domain_init() would: Success when
+ * !is_iommu_enabled(), following from !iommu_enabled when
!HAS_PASSTHROUGH
+ */
From: Denis Mukhin
Add new CONRING_SHIFT Kconfig parameter to specify the boot console buffer size
as a power of 2.
The supported range is [14..27] -> [16KiB..128MiB].
Set default to 15 (32 KiB).
Link: https://gitlab.com/xen-project/xen/-/issues/185
Signed-off-by: Denis Mukhin
---
Changes v2-
On Fri, Feb 07, 2025 at 02:37:24PM +, David Woodhouse wrote:
> From: David Woodhouse
>
> Block devices don't work in PV Grub (0.9x) if there is no mode specified. It
> complains: "Error ENOENT when reading the mode"
>
> Signed-off-by: David Woodhouse
Reviewed-by: Anthony PERARD
Thanks,
On 06.03.2025 18:56, Roger Pau Monné wrote:
> On Thu, Mar 06, 2025 at 05:45:27PM +0100, Jan Beulich wrote:
>> On 06.03.2025 15:57, Roger Pau Monne wrote:
>>> Instead compose a dummy MSI message just for the purpose of getting the
>>> delivery attributes, which are the same for all messages. Note t
On 07.03.2025 11:11, Jan Beulich wrote:
Sorry, missed
From: Juergen Gross
Jan
> VIRQs are split into "global" and "per vcpu" ones. Unfortunately in
> reality there are "per domain" ones, too.
>
> send_global_virq() and set_global_virq_handler() make only sense for
> the real "global" ones, so
VIRQs are split into "global" and "per vcpu" ones. Unfortunately in
reality there are "per domain" ones, too.
send_global_virq() and set_global_virq_handler() make only sense for
the real "global" ones, so replace virq_is_global() with a new
function get_virq_type() returning one of the 3 possible
On 07.03.2025 10:20, Luca Fancellu wrote:
> Hi Julien,
>
>> On 7 Mar 2025, at 09:09, Julien Grall wrote:
>>
>> Hi Luca,
>>
>> On 07/03/2025 07:58, Luca Fancellu wrote:
>>> When Xen is built without HAS_PASSTHROUGH, there are some parts
>>> in arm where iommu_* functions are called in the codebase
On 07/03/2025 09:20, Luca Fancellu wrote:
On 7 Mar 2025, at 09:09, Julien Grall wrote:
/*
* The following flags are passed to map (applicable ones also to unmap)
* operations, while some are passed back by lookup operations.
@@ -209,6 +233,8 @@ struct msi_msg;
#ifdef CONFIG_HAS_DEV
On Thursday, March 6th, 2025 at 8:35 AM, Jan Beulich wrote:
>
>
> On 06.03.2025 08:59, dm...@proton.me wrote:> --- a/xen/include/xen/consoled.h
>
> > +++ b/xen/include/xen/consoled.h
> > @@ -1,12 +1,23 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > #ifndef XEN_CONSOLED_H
> > #define X
On 07.03.2025 02:09, Andrew Cooper wrote:
> On 05/03/2025 2:01 pm, Jan Beulich wrote:
>> On 05.03.2025 01:02, Andrew Cooper wrote:
>>> This can be a plain per_cpu() variable, and __read_mostly seeing as it's
>>> allocated once and never touched again.
>> cpu_smpboot_free() certainly touches (really
Hi Luca,
On 07/03/2025 07:58, Luca Fancellu wrote:
When Xen is built without HAS_PASSTHROUGH, there are some parts
in arm where iommu_* functions are called in the codebase, but
their implementation is under xen/drivers/passthrough that is
not built.
So provide some stub for these functions in
Hi,
On 06/03/2025 22:03, Jason Andryuk wrote:
Add capabilities property to dom0less to allow building a
disaggregated system.
Introduce bootfdt.h to contain these constants.
When using the hardware or xenstore capabilities, adjust the grant and
event channel limits similar to dom0.
> > Also f
On 07.03.2025 09:48, Jan Beulich wrote:
> On 07.03.2025 00:35, Andrew Cooper wrote:
>> We've already scanned features by the time init_e820() is called. Remove the
>> cpuid() calls.
>>
>> Signed-off-by: Andrew Cooper
>
> Reviewed-by: Jan Beulich
>
>> Backporting. Not sure it's worth backporin
On 06.03.25 21:15, Stewart Hildebrand wrote:
> On 2/24/25 04:18, Mykyta Poturai wrote:
>> From: Oleksandr Andrushchenko
>>
>> Add support for Renesas R-Car Gen4 PCI host controller.
>> S4 and V4H SoCs are supported.
>> Implement config read/write operations for both root and child buses.
>> For ac
On 07.03.2025 08:05, Juergen Gross wrote:
> @@ -913,7 +917,7 @@ void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq)
> struct domain *d;
> struct evtchn *chn;
>
> -ASSERT(!virq_is_global(virq));
> +ASSERT(get_virq_type(virq) == VIRQ_VCPU);
>
> read_lock_irqsave(&v->vi
On 06.03.2025 22:29, Andrew Cooper wrote:
> On 05/03/2025 9:23 am, Jan Beulich wrote:
>> On 04.03.2025 00:29, Andrew Cooper wrote:
>>> --- a/xen/include/xen/sched.h
>>> +++ b/xen/include/xen/sched.h
>>> @@ -645,7 +645,7 @@ struct domain
>>> unsigned int num_llc_colors;
>>> const unsigned
On 06.03.2025 23:03, Jason Andryuk wrote:
> Assign domid 0 to the hwdom. Normally, dom0less does not use domid 0.
>
> This fixes using the Xen console which assumes domid 0 to use the
> hypercall interface.
Iirc a patch by Denis Mukhin is taking care of that, if what's meant is
the input focus s
Hi,
On 06/03/2025 22:03, Jason Andryuk wrote:
Assign domid 0 to the hwdom. Normally, dom0less does not use domid 0.
A few years ago, we went to great length to avoid making the assumption
that the hardware domain is domid 0. See all the calls to
"is_hardware_domain()". So I am reluctant to
On 07/03/2025 08:28, Jan Beulich wrote:
>
>
> On 06.03.2025 18:25, GitLab wrote:
>>
>>
>> Pipeline #1703410235 has failed!
>>
>> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
>> Branch: staging (
>> https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
>>
>> Commit: f
When Xen is built without HAS_PASSTHROUGH, there are some parts
in arm where iommu_* functions are called in the codebase, but
their implementation is under xen/drivers/passthrough that is
not built.
So provide some stub for these functions in order to build Xen
when !HAS_PASSTHROUGH, which is the
Hi all,
in order to build Xen for Arm64 with MPU support, there are few changes to
support the compilation of Arm code without HAS_PASSTHROUGH and some Kconfig
changes.
Luca Fancellu (2):
xen/passthrough: Provide stub functions when !HAS_PASSTHROUGH
xen/arm: Restrict Kconfig configuration for
72 matches
Mail list logo
