[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH v3 1/7] xen/arm: add generic SCI subsystem


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>
  • Date: Mon, 24 Mar 2025 13:11:06 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CvDGwbdZo8ARdx0B9NdsufmR/vzlAwwKZLi4lHYNGYQ=; b=HBJqmyv5rXa4/FeypJ+FTDyCoJB+ZX3FhrNiIe4yJgbPvrZGADu23tdJLOVa2zv7TWPq+FCDi5StRo6+iv/HFyeBLW7iVoDzo8oAOlx+Uj0f4vKBPBKezqej1jrEQru76Op2KwhLGdwhRvI/kIcmME1+sCoKsWyY3pD2S6fvwxV7tSWKwgdNbvXeuB6NHRvX13Bbu6e9n8q+2jjOtmgURnYn54xoxDljuylYKEpp/4T85I3RrDGVE59ulINx22UF9LH50iA+RHvpKSecWa7/Odd3g8BGDiNJWckEdJJSM+MywXnadHFp0n3CrT9oDhxVBEUPXT7IzHrvHAruXjLvJg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=CAenr9ddtQ4p7c1M2rN/8ZpZZUrSqeoWWUxXhwaipDDtHacyb24boFHFMxzjR4XNBzZagDMC0Vj7VRYSY9+wWzEjNSmrwHnU/N18keJXYMBEV9EgtVE4toZCnHOZARilSxSUohArk1PV//fS1jLc7Gf/otUjOqNbXimCO1bW7eYdeF16yyUX265/Pi8twOZgbBYfPiI9ovf4pHcw2PD2yX0ilH2NlFPKbdM7Y1k8t+A/1KvM0q4LCKC3+Y+ooPajfGBiH5nJkc/T5V9PF5vCqYAgrvttWK/JipCvzZcJerF2CJASY9qldS2O/4ri9yypY5zMPnUKdX4XHCbRyvn1jA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Grygorii Strashko <grygorii_strashko@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Grygorii Strashko <gragst.linux@xxxxxxxxx>
  • Delivery-date: Mon, 24 Mar 2025 13:11:18 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHbkncOeD3VtJHazEm60TGwzYlR9LNt0I6AgBRAzACAABJNAIAAM9CA
  • Thread-topic: [RFC PATCH v3 1/7] xen/arm: add generic SCI subsystem

Hi Jan,

On 24/03/2025 12:05, Jan Beulich wrote:
> On 24.03.2025 10:00, Oleksii Moisieiev wrote:
>> 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.
>> 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.
> Except that "an existing padding field" means a field which isn't just
> there in space, but is also checked to be zero right now. That is, new
> code setting the field to non-zero needs to properly get an error
> indicator back from an older hypervisor.

I completely agree with you that XEN_DOMCTL_INTERFACE_VERSION should be 
incremented

before the changes are merged. I just wanted to point out that we do not 
exceed the size of the xen_domctl padding. If you are okay with the 
fields we have added, then XEN_DOMCTL_INTERFACE_VERSION will be updated 
in the next patch series.

> but is also checked to be zero right now.

Just out of curiosity, I have one more question: I couldn't find the 
check you've mentioned. Could you point me to where Xen or

the toolstack checks the domctl structure for 0? I would greatly 
appreciate it if you could show me.


WBR,

Oleksii.

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.