[PATCH] xen/arm: XEN_DOMCTL_get_address_size hypercall support

[PATCH] xen/arm: XEN_DOMCTL_get_address_size hypercall support

[Milan Djokic]

Signed-off-by: Milan Djokic <milan_djokic@epam.com>

---
XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86)
It would be useful to have this hypercall supported for arm64, in order to get
current guest addressing mode and also to verify that XEN_DOMCTL_set_address_size
performs switch to target addressing mode (instead of relying on its returned error code only).
---
 xen/arch/arm/arm64/domctl.c       | 46 +++++++++++++++++++++++++++++--
 xen/arch/arm/domain.c             |  5 ++++
 xen/arch/arm/include/asm/domain.h |  1 +
 3 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
index 8720d126c9..f227309e06 100644
--- a/xen/arch/arm/arm64/domctl.c
+++ b/xen/arch/arm/arm64/domctl.c
@@ -12,6 +12,7 @@
 #include <public/domctl.h>
 #include <asm/arm64/sve.h>
 #include <asm/cpufeature.h>
+#include <xen/guest_access.h>
 
 static long switch_mode(struct domain *d, enum domain_type type)
 {
@@ -33,6 +34,37 @@ static long switch_mode(struct domain *d, enum domain_type type)
     return 0;
 }
 
+static long get_address_size(struct domain *d, uint32_t *address_size)
+{
+    long rc = 0;
+    struct vcpu *v;
+    /* Check invalid arguments */
+    if ( d == NULL || address_size == NULL) {
+        rc = -EINVAL;
+    }
+    /* Domain structure type field and actual vcpu mode must be aligned */
+    if(rc == 0) {
+        for_each_vcpu(d, v) {
+            if(vcpu_get_mode(v) != d->arch.type) {
+                rc = -EFAULT;
+            }
+        }
+    }
+
+    if(rc == 0) {
+        if(d->arch.type == DOMAIN_32BIT) {
+            *address_size = 32U;
+        }
+        else if(d->arch.type == DOMAIN_64BIT) {
+            *address_size = 64U;
+        }
+        else {
+            rc = -EFAULT;
+        }
+    }
+    return rc;
+}
+
 static long set_address_size(struct domain *d, uint32_t address_size)
 {
     switch ( address_size )
@@ -54,14 +86,22 @@ static long set_address_size(struct domain *d, uint32_t address_size)
 long subarch_do_domctl(struct xen_domctl *domctl, struct domain *d,
                        XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
+    long rc = 0;
     switch ( domctl->cmd )
     {
     case XEN_DOMCTL_set_address_size:
-        return set_address_size(d, domctl->u.address_size.size);
-
+        rc = set_address_size(d, domctl->u.address_size.size);
+        break;
+    case XEN_DOMCTL_get_address_size:
+        rc = get_address_size(d, &domctl->u.address_size.size);
+        if(__copy_to_guest(u_domctl, domctl, 1)) {
+            rc = -EFAULT;
+        }
+        break;
     default:
-        return -ENOSYS;
+        rc = -ENOSYS;
     }
+    return rc;
 }
 
 /*
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1a8585d02b..9096dc7411 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -608,6 +608,11 @@ void vcpu_switch_to_aarch64_mode(struct vcpu *v)
     v->arch.hcr_el2 |= HCR_RW;
 }
 
+unsigned int vcpu_get_mode(struct vcpu *v)
+{
+    return v->arch.hcr_el2 & HCR_RW ? DOMAIN_64BIT : DOMAIN_32BIT;
+}
+
 int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
 {
     unsigned int max_vcpus;
diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h
index af3e168374..e64402a67d 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -252,6 +252,7 @@ struct arch_vcpu
 
 void vcpu_show_registers(struct vcpu *v);
 void vcpu_switch_to_aarch64_mode(struct vcpu *v);
+unsigned int vcpu_get_mode(struct vcpu *v);
 
 /*
  * Due to the restriction of GICv3, the number of vCPUs in AFF0 is
-- 
2.43.0

Re: [PATCH] xen/arm: XEN_DOMCTL_get_address_size hypercall support

[Andrew Cooper]

On 01/10/2025 9:01 pm, Milan Djokic wrote:
> Signed-off-by: Milan Djokic <milan_djokic@epam.com>
>
> ---
> XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86)
> It would be useful to have this hypercall supported for arm64, in order to get
> current guest addressing mode and also to verify that XEN_DOMCTL_set_address_size
> performs switch to target addressing mode (instead of relying on its returned error code only).

Please don't copy this misfeature of x86 PV guests into ARM.

Letting domains be of variable bitness after domain create leads to a
whole lot of bugs, many security relevant.

32bit vs 64bit should be an input to domain_create(), not something that
is edited after the domain has been constructed.

> diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
> index 8720d126c9..f227309e06 100644
> --- a/xen/arch/arm/arm64/domctl.c
> +++ b/xen/arch/arm/arm64/domctl.c
> @@ -33,6 +34,37 @@ static long switch_mode(struct domain *d, enum domain_type type)
>      return 0;
>  }
>  
> +static long get_address_size(struct domain *d, uint32_t *address_size)
> +{
> +    long rc = 0;
> +    struct vcpu *v;
> +    /* Check invalid arguments */
> +    if ( d == NULL || address_size == NULL) {
> +        rc = -EINVAL;
> +    }
> +    /* Domain structure type field and actual vcpu mode must be aligned */
> +    if(rc == 0) {
> +        for_each_vcpu(d, v) {
> +            if(vcpu_get_mode(v) != d->arch.type) {
> +                rc = -EFAULT;
> +            }
> +        }

This is deeply suspicious.

Under what circumstances can the vCPU setting be different from the
domain setting?

~Andrew

Re: [PATCH] xen/arm: XEN_DOMCTL_get_address_size hypercall support

[Milan Djokic]

Hello Andrew,

On 10/2/25 12:10, Andrew Cooper wrote:
> On 01/10/2025 9:01 pm, Milan Djokic wrote:
>> Signed-off-by: Milan Djokic <milan_djokic@epam.com>
>>
>> ---
>> XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86)
>> It would be useful to have this hypercall supported for arm64, in order to get
>> current guest addressing mode and also to verify that XEN_DOMCTL_set_address_size
>> performs switch to target addressing mode (instead of relying on its returned error code only).
> 
> Please don't copy this misfeature of x86 PV guests into ARM.
> 
> Letting domains be of variable bitness after domain create leads to a
> whole lot of bugs, many security relevant.
> 
> 32bit vs 64bit should be an input to domain_create(), not something that
> is edited after the domain has been constructed.
> 

Yes, the idea behind this patch is not to introduce variable bitness, 
just to have the ability to get current addressing mode through 
hypercall. In our case, we have used it only in domain creation path 
(after domain_create(), to verify that target addressing mode is set).
Of course, whether this hypercall support would be useful in mainline is 
open for discussion.

>> diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
>> index 8720d126c9..f227309e06 100644
>> --- a/xen/arch/arm/arm64/domctl.c
>> +++ b/xen/arch/arm/arm64/domctl.c
>> @@ -33,6 +34,37 @@ static long switch_mode(struct domain *d, enum domain_type type)
>>       return 0;
>>   }
>>   
>> +static long get_address_size(struct domain *d, uint32_t *address_size)
>> +{
>> +    long rc = 0;
>> +    struct vcpu *v;
>> +    /* Check invalid arguments */
>> +    if ( d == NULL || address_size == NULL) {
>> +        rc = -EINVAL;
>> +    }
>> +    /* Domain structure type field and actual vcpu mode must be aligned */
>> +    if(rc == 0) {
>> +        for_each_vcpu(d, v) {
>> +            if(vcpu_get_mode(v) != d->arch.type) {
>> +                rc = -EFAULT;
>> +            }
>> +        }
> 
> This is deeply suspicious.
> 
> Under what circumstances can the vCPU setting be different from the
> domain setting?
> 

It should never happen, this is more of a sanity check. Alternative 
would be to use only one of vCPU or domain settings, checking against 
both seemed more complete to me.

> ~Andrew

BR,
Milan

Re: [PATCH] xen/arm: XEN_DOMCTL_get_address_size hypercall support

[Julien Grall]

Hi,

On 02/10/2025 12:10, Milan Djokic wrote:
> Hello Andrew,
> 
> On 10/2/25 12:10, Andrew Cooper wrote:
>> On 01/10/2025 9:01 pm, Milan Djokic wrote:
>>> Signed-off-by: Milan Djokic <milan_djokic@epam.com>
>>>
>>> ---
>>> XEN_DOMCTL_get_address_size hypercall is not implemented for arm 
>>> (only for x86)
>>> It would be useful to have this hypercall supported for arm64, in 
>>> order to get
>>> current guest addressing mode and also to verify that 
>>> XEN_DOMCTL_set_address_size
>>> performs switch to target addressing mode (instead of relying on its 
>>> returned error code only).
>>
>> Please don't copy this misfeature of x86 PV guests into ARM.
>>
>> Letting domains be of variable bitness after domain create leads to a
>> whole lot of bugs, many security relevant.
>>
>> 32bit vs 64bit should be an input to domain_create(), not something that
>> is edited after the domain has been constructed.
>>
> 
> Yes, the idea behind this patch is not to introduce variable bitness, 
> just to have the ability to get current addressing mode through 
> hypercall. In our case, we have used it only in domain creation path 
> (after domain_create(), to verify that target addressing mode is set).
> Of course, whether this hypercall support would be useful in mainline is 
> open for discussion.

We already have a series under review [1] that follow what Andrew is 
suggesting. I would rather focus on getting it committed rather than 
trying to workaround it.

> 
>>> diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
>>> index 8720d126c9..f227309e06 100644
>>> --- a/xen/arch/arm/arm64/domctl.c
>>> +++ b/xen/arch/arm/arm64/domctl.c
>>> @@ -33,6 +34,37 @@ static long switch_mode(struct domain *d, enum 
>>> domain_type type)
>>>       return 0;
>>>   }
>>> +static long get_address_size(struct domain *d, uint32_t *address_size)
>>> +{
>>> +    long rc = 0;
>>> +    struct vcpu *v;
>>> +    /* Check invalid arguments */
>>> +    if ( d == NULL || address_size == NULL) {
>>> +        rc = -EINVAL;
>>> +    }
>>> +    /* Domain structure type field and actual vcpu mode must be 
>>> aligned */
>>> +    if(rc == 0) {
>>> +        for_each_vcpu(d, v) {
>>> +            if(vcpu_get_mode(v) != d->arch.type) {
>>> +                rc = -EFAULT;
>>> +            }
>>> +        }
>>
>> This is deeply suspicious.
>>
>> Under what circumstances can the vCPU setting be different from the
>> domain setting?
>>
> 
> It should never happen, this is more of a sanity check. Alternative 
> would be to use only one of vCPU or domain settings, checking against 
> both seemed more complete to me.

This would be a logical error in Xen rather than something that could be 
triggered by the toolstack. I feel it could mislead people using release 
build because the fault is not due to the input provided.

Cheers,

-- 
Julien Grall

Re: [PATCH] xen/arm: XEN_DOMCTL_get_address_size hypercall support

[Milan Djokic]

Hi Julien,

On 10/2/25 14:43, Julien Grall wrote:
> Hi,
> 
> On 02/10/2025 12:10, Milan Djokic wrote:
>> Hello Andrew,
>>
>> On 10/2/25 12:10, Andrew Cooper wrote:
>>> On 01/10/2025 9:01 pm, Milan Djokic wrote:
>>>> Signed-off-by: Milan Djokic <milan_djokic@epam.com>
>>>>
>>>> ---
>>>> XEN_DOMCTL_get_address_size hypercall is not implemented for arm
>>>> (only for x86)
>>>> It would be useful to have this hypercall supported for arm64, in
>>>> order to get
>>>> current guest addressing mode and also to verify that
>>>> XEN_DOMCTL_set_address_size
>>>> performs switch to target addressing mode (instead of relying on its
>>>> returned error code only).
>>>
>>> Please don't copy this misfeature of x86 PV guests into ARM.
>>>
>>> Letting domains be of variable bitness after domain create leads to a
>>> whole lot of bugs, many security relevant.
>>>
>>> 32bit vs 64bit should be an input to domain_create(), not something that
>>> is edited after the domain has been constructed.
>>>
>>
>> Yes, the idea behind this patch is not to introduce variable bitness,
>> just to have the ability to get current addressing mode through
>> hypercall. In our case, we have used it only in domain creation path
>> (after domain_create(), to verify that target addressing mode is set).
>> Of course, whether this hypercall support would be useful in mainline is
>> open for discussion.
> 
> We already have a series under review [1] that follow what Andrew is
> suggesting. I would rather focus on getting it committed rather than
> trying to workaround it.
> 
Thank you for clarification. In that case, I will abandon this patch.
You are referring to path series from Grygorii [1]? This means that 
XEN_DOMCTL_set_address_size hypercall will be removed and its function 
integrated as part of domain_create() and XEN_DOMCTL_createdomain (for 
toolstack) hypercall?

>>
>>>> diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
>>>> index 8720d126c9..f227309e06 100644
>>>> --- a/xen/arch/arm/arm64/domctl.c
>>>> +++ b/xen/arch/arm/arm64/domctl.c
>>>> @@ -33,6 +34,37 @@ static long switch_mode(struct domain *d, enum
>>>> domain_type type)
>>>>        return 0;
>>>>    }
>>>> +static long get_address_size(struct domain *d, uint32_t *address_size)
>>>> +{
>>>> +    long rc = 0;
>>>> +    struct vcpu *v;
>>>> +    /* Check invalid arguments */
>>>> +    if ( d == NULL || address_size == NULL) {
>>>> +        rc = -EINVAL;
>>>> +    }
>>>> +    /* Domain structure type field and actual vcpu mode must be
>>>> aligned */
>>>> +    if(rc == 0) {
>>>> +        for_each_vcpu(d, v) {
>>>> +            if(vcpu_get_mode(v) != d->arch.type) {
>>>> +                rc = -EFAULT;
>>>> +            }
>>>> +        }
>>>
>>> This is deeply suspicious.
>>>
>>> Under what circumstances can the vCPU setting be different from the
>>> domain setting?
>>>
>>
>> It should never happen, this is more of a sanity check. Alternative
>> would be to use only one of vCPU or domain settings, checking against
>> both seemed more complete to me.
> 
> This would be a logical error in Xen rather than something that could be
> triggered by the toolstack. I feel it could mislead people using release
> build because the fault is not due to the input provided.
> 
> Cheers,
>
[1] 
https://patchwork.kernel.org/project/xen-devel/cover/20250911082034.1326377-1-grygorii_strashko@epam.com/

BR,
Milan

Re: [PATCH] xen/arm: XEN_DOMCTL_get_address_size hypercall support

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 940 bytes --]

On 10/2/25 06:10, Andrew Cooper wrote:
> On 01/10/2025 9:01 pm, Milan Djokic wrote:
>> Signed-off-by: Milan Djokic <milan_djokic@epam.com>
>>
>> ---
>> XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86)
>> It would be useful to have this hypercall supported for arm64, in order to get
>> current guest addressing mode and also to verify that XEN_DOMCTL_set_address_size
>> performs switch to target addressing mode (instead of relying on its returned error code only).
> 
> Please don't copy this misfeature of x86 PV guests into ARM.
> 
> Letting domains be of variable bitness after domain create leads to a
> whole lot of bugs, many security relevant.
> 
> 32bit vs 64bit should be an input to domain_create(), not something that
> is edited after the domain has been constructed.

Does this mean that Xen guests cannot support multiarch?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] xen/arm: XEN_DOMCTL_get_address_size hypercall support

[Alejandro Vallejo]

On Thu Oct 2, 2025 at 8:27 PM CEST, Demi Marie Obenour wrote:
> On 10/2/25 06:10, Andrew Cooper wrote:
>> On 01/10/2025 9:01 pm, Milan Djokic wrote:
>>> Signed-off-by: Milan Djokic <milan_djokic@epam.com>
>>>
>>> ---
>>> XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86)
>>> It would be useful to have this hypercall supported for arm64, in order to get
>>> current guest addressing mode and also to verify that XEN_DOMCTL_set_address_size
>>> performs switch to target addressing mode (instead of relying on its returned error code only).
>> 
>> Please don't copy this misfeature of x86 PV guests into ARM.
>> 
>> Letting domains be of variable bitness after domain create leads to a
>> whole lot of bugs, many security relevant.
>> 
>> 32bit vs 64bit should be an input to domain_create(), not something that
>> is edited after the domain has been constructed.
>
> Does this mean that Xen guests cannot support multiarch?

HVM/PVH x86_64 cannot not be multiarch. All APs start in 16bit and proceed to
32 and 64 bit mode, in that order.

It's only PV that has fixed bitness.

Cheers,
Alejandro

Re: [PATCH] xen/arm: XEN_DOMCTL_get_address_size hypercall support

[Julien Grall]

Hi Demi,

On 02/10/2025 19:27, Demi Marie Obenour wrote:
> On 10/2/25 06:10, Andrew Cooper wrote:
>> On 01/10/2025 9:01 pm, Milan Djokic wrote:
>>> Signed-off-by: Milan Djokic <milan_djokic@epam.com>
>>>
>>> ---
>>> XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86)
>>> It would be useful to have this hypercall supported for arm64, in order to get
>>> current guest addressing mode and also to verify that XEN_DOMCTL_set_address_size
>>> performs switch to target addressing mode (instead of relying on its returned error code only).
>>
>> Please don't copy this misfeature of x86 PV guests into ARM.
>>
>> Letting domains be of variable bitness after domain create leads to a
>> whole lot of bugs, many security relevant.
>>
>> 32bit vs 64bit should be an input to domain_create(), not something that
>> is edited after the domain has been constructed.
> 
> Does this mean that Xen guests cannot support multiarch?

I can't speak for x86. But for Arm, the endianess of EL1 (OS) is fixed 
when the vCPU is booting. You could in theory have a domain with a mix 
of 64-bit and 32-bit vCPUs. But that's not supported by Xen (all vCPUs 
should have the same bitness) and also I am not aware of any mainstream 
OS able to deal with multiple bitness. Most likely, you will need to run 
two OSes and create your custom OS.

Also, I believe XEN_DOMCTL_get_address_size would not be suitable for 
such setup.

Cheers,

-- 
Julien Grall

Re: [PATCH] xen/arm: XEN_DOMCTL_get_address_size hypercall support

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 1738 bytes --]

On 10/3/25 06:14, Julien Grall wrote:
> Hi Demi,
> 
> On 02/10/2025 19:27, Demi Marie Obenour wrote:
>> On 10/2/25 06:10, Andrew Cooper wrote:
>>> On 01/10/2025 9:01 pm, Milan Djokic wrote:
>>>> Signed-off-by: Milan Djokic <milan_djokic@epam.com>
>>>>
>>>> ---
>>>> XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86)
>>>> It would be useful to have this hypercall supported for arm64, in order to get
>>>> current guest addressing mode and also to verify that XEN_DOMCTL_set_address_size
>>>> performs switch to target addressing mode (instead of relying on its returned error code only).
>>>
>>> Please don't copy this misfeature of x86 PV guests into ARM.
>>>
>>> Letting domains be of variable bitness after domain create leads to a
>>> whole lot of bugs, many security relevant.
>>>
>>> 32bit vs 64bit should be an input to domain_create(), not something that
>>> is edited after the domain has been constructed.
>>
>> Does this mean that Xen guests cannot support multiarch?
> 
> I can't speak for x86. But for Arm, the endianess of EL1 (OS) is fixed 
> when the vCPU is booting. You could in theory have a domain with a mix 
> of 64-bit and 32-bit vCPUs. But that's not supported by Xen (all vCPUs 
> should have the same bitness) and also I am not aware of any mainstream 
> OS able to deal with multiple bitness. Most likely, you will need to run 
> two OSes and create your custom OS.
> 
> Also, I believe XEN_DOMCTL_get_address_size would not be suitable for 
> such setup.

I meant multiarch in userspace.  Running a 32-bit kernel makes no sense.
If that is something Arm OSs just don't support that's fine too.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] xen/arm: XEN_DOMCTL_get_address_size hypercall support

[Julien Grall]

Hi Demi,

On 03/10/2025 17:03, Demi Marie Obenour wrote:
> On 10/3/25 06:14, Julien Grall wrote:
>> Hi Demi,
>>
>> On 02/10/2025 19:27, Demi Marie Obenour wrote:
>>> On 10/2/25 06:10, Andrew Cooper wrote:
>>>> On 01/10/2025 9:01 pm, Milan Djokic wrote:
>>>>> Signed-off-by: Milan Djokic <milan_djokic@epam.com>
>>>>>
>>>>> ---
>>>>> XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86)
>>>>> It would be useful to have this hypercall supported for arm64, in order to get
>>>>> current guest addressing mode and also to verify that XEN_DOMCTL_set_address_size
>>>>> performs switch to target addressing mode (instead of relying on its returned error code only).
>>>>
>>>> Please don't copy this misfeature of x86 PV guests into ARM.
>>>>
>>>> Letting domains be of variable bitness after domain create leads to a
>>>> whole lot of bugs, many security relevant.
>>>>
>>>> 32bit vs 64bit should be an input to domain_create(), not something that
>>>> is edited after the domain has been constructed.
>>>
>>> Does this mean that Xen guests cannot support multiarch?
>>
>> I can't speak for x86. But for Arm, the endianess of EL1 (OS) is fixed
>> when the vCPU is booting. You could in theory have a domain with a mix
>> of 64-bit and 32-bit vCPUs. But that's not supported by Xen (all vCPUs
>> should have the same bitness) and also I am not aware of any mainstream
>> OS able to deal with multiple bitness. Most likely, you will need to run
>> two OSes and create your custom OS.
>>
>> Also, I believe XEN_DOMCTL_get_address_size would not be suitable for
>> such setup.
> 
> I meant multiarch in userspace.  Running a 32-bit kernel makes no sense.

I think some people may disagree :). We are in process of adding support 
for 32-bit MPU in Xen.

> If that is something Arm OSs just don't support that's fine too.

HCR_EL2.RW is only forcing 64-bit in EL1 (kernel mode). It is still 
possible to run 32-bit applicate in userland as long as the process 
supports it.

Cheers,

-- 
Julien Grall

Re: [PATCH] xen/arm: XEN_DOMCTL_get_address_size hypercall support

[Alejandro Vallejo]

On Wed Oct 1, 2025 at 10:01 PM CEST, Milan Djokic wrote:
> Signed-off-by: Milan Djokic <milan_djokic@epam.com>
>
> ---
> XEN_DOMCTL_get_address_size hypercall is not implemented for arm (only for x86)
> It would be useful to have this hypercall supported for arm64, in order to get
> current guest addressing mode

Why is this helpful? You're racing against the guest transitioning between 32
and 64 bits, so the result is stale by the time you read it.

Do you care about the instantanerous bitness of the vCPU or whether you
created a 32 or 64 bit guest?

> and also to verify that XEN_DOMCTL_set_address_size
> performs switch to target addressing mode (instead of relying on its returned error code only).

You can't use that in HVM. Even if you could, why would you? What's the ultimate
goal?

Cheers,
Alejandro