On 2025-03-07 11:26, Andrew Cooper wrote:
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 rem
On 06.03.2025 23:03, Jason Andryuk wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -699,7 +699,7 @@ struct domain *domain_create(domid_t domid,
> d->is_privileged = flags & CDF_privileged;
>
> /* Sort out our idea of is_hardware_domain(). */
> -if ( domid == 0 ||
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-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 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 creation.
>
> Signed-off-by: Danie
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 creation.
Signed-off-by: Daniel P. Smith
Signed-off-by: Jason Andryuk
---
xen/arch/ar
