Hi Jan,
Let me answer one of your comment. Please see below:
On 11/03/2025 13:43, Jan Beulich wrote:
> On 11.03.2025 12:16, Grygorii Strashko wrote:
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -526,6 +526,12 @@ S: Supported
>> F: xen/arch/arm/include/asm/tee/
[snip]
>> --- a/xen/include/public/arch-arm.h
>> +++ b/xen/include/public/arch-arm.h
>> @@ -327,6 +327,8 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
>> #define XEN_DOMCTL_CONFIG_TEE_OPTEE 1
>> #define XEN_DOMCTL_CONFIG_TEE_FFA 2
>>
>> +#define XEN_DOMCTL_CONFIG_ARM_SCI_NONE 0
>> +
>> struct xen_arch_domainconfig {
>> /* IN/OUT */
>> uint8_t gic_version;
>> @@ -350,6 +352,8 @@ struct xen_arch_domainconfig {
>> *
>> */
>> uint32_t clock_frequency;
>> + /* IN */
>> + uint8_t arm_sci_type;
>> };
> You're not re-using a pre-existing padding field, so I don't see how you
> can get away without bumping XEN_DOMCTL_INTERFACE_VERSION.
>
> Jan
We are reusing an existing padding field in xen_domctl, which is defined
as pad[128].
The xen_arch_domainconfig structure is a part of the following domctl
structures:
- xen_domctl_createdomain
- xen_domctl_getdomaininfo
These structures are included in the union within xen_domctl, which
defines pad[128] for padding.
In the following example, I used the pahole tool to inspect the current
structure sizes for the
xen_domctl structure:
> pahole xen-syms -C xen_domctl
The result is as follows:
struct xen_domctl {
uint32_t cmd; /* 0 4 */
uint32_t interface_version; /* 4
4 */
domid_t domain; /* 8 2 */
uint16_t _pad[3]; /* 10
6 */
union {
struct xen_domctl_createdomain createdomain; /*
16 76 */
struct xen_domctl_getdomaininfo getdomaininfo
__attribute__((__aligned__(8))); /* 16 120 */
...
uint8_t pad[128]; /* 16 128 */
};
Both structures, xen_domctl_createdomain and xen_domctl_getdomaininfo,
do not exceed the size of the 128-byte padding.
WBR,
Oleksii.
