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

Re: [PATCH v5 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers


  • To: Julien Grall <julien@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Leonid Komarianskyi <Leonid_Komarianskyi@xxxxxxxx>
  • Date: Tue, 2 Sep 2025 20:55:12 +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=bN/MR7wiZDcyYcAlpQvmaGF4GxqF1x0A4lpNK/Q18eo=; b=Ir+BXWP8emf0NlsOLkLfysznOoZB2CNUD8mLhWb1C/tn44lB/QAydUaKurEjBjmQvImhSnWBRhV0Shbm3lNE0yTPew4zn3b3B7KNqX8YwKiCmuOnwV3BctLbc1WObOpn9TyRhpgAf7VrXMEnavSb/xQ1jsUCR2EN9gkZnLinb6yTGvvWmOSa8Gb7TH9zp3dkLGIa/6B1x1ZA9x2OcNEdw9m0SlccG+1rNE5EBFh38kvYJtOriN860cAZE6Ok93HbBzM9PUcrybS5+iL7WRHC3H/8ub3YCkY4qu28L2QPERbe8KpWjG/IFGqBTYAY0QiIeImLD1qQoxZr/D1JDYNNkw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QpHKkXgRsCMc5+wubH/XlB2kLZKR7dURo9nMjLmrSrK0G7mGIT2kPa+K19ZbDVlIUsqSVuwpzCQ2KhAgEJCIite8imTVkLeVcwdRVeQjZmXQxmf273bomevTYceJb//NhcU2AW0XeLTwJZlZDoOI6Ec/D1lHwW9tt+U2DECCVp6tsunrGr8v2t5+8ofgqQ3xx0VhF5S2pOz2413Vkve1Vvvc3uXC2WeOlkFjaI93TdUbc4UJakKcxBbE+m93H5Buab0ov9fDKscUDTqsTxTbPeLD8OCgN1htUEyuoEYLCS8+/czC24V/XywVF+6brScLN2n0GH2VKmqP9gGK/Wb9Rw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: "olekstysh@xxxxxxxxx" <olekstysh@xxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Tue, 02 Sep 2025 20:55:22 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHcGP7lSnKp01vKiUyg8GCh+goOA7SAIt4AgAAIk4CAADCcAIAACbGA
  • Thread-topic: [PATCH v5 10/12] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers

Hi Julien,

On 02.09.25 23:20, Julien Grall wrote:
> Hi Leonid,
> 
> On 02/09/2025 18:26, Leonid Komarianskyi wrote:
>> Hi Julien,
>>
>> Thank you for your review and suggestions.
>>
>> On 02.09.25 19:55, Julien Grall wrote:
>>> Hi Leonid,
>>>
>>> On 29/08/2025 17:06, Leonid Komarianskyi wrote:
>>>> @@ -782,46 +804,81 @@ static int
>>>> __vgic_v3_distr_common_mmio_write(const char *name, struct vcpu *v,
>>>>        {
>>>>        case VRANGE32(GICD_IGROUPR, GICD_IGROUPRN):
>>>>        case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN):
>>>> +    case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN):
>>>> +    case VRANGE32(GICD_IGRPMODRnE, GICD_IGRPMODRnEN):
>>>>            /* We do not implement security extensions for guests, write
>>>> ignore */
>>>>            goto write_ignore_32;
>>>>        case VRANGE32(GICD_ISENABLER, GICD_ISENABLERN):
>>>> +    case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN):
>>>>            if ( dabt.size != DABT_WORD ) goto bad_width;
>>>> -        rank = vgic_rank_offset(v, 1, reg - GICD_ISENABLER, 
>>>> DABT_WORD);
>>>> +        if ( reg >= GICD_ISENABLERnE )
>>>> +            rank = vgic_ext_rank_offset(v, 1, reg - GICD_ISENABLERnE,
>>>> +                                        DABT_WORD);
>>>> +        else
>>>> +            rank = vgic_rank_offset(v, 1, reg - GICD_ISENABLER,
>>>> DABT_WORD);
>>>
>>> While I understand the desire to try to avoid code duplication. I feel
>>> this is making the code a lot more complicating and in fact riskier
>>> because...
>>>
>>>>            if ( rank == NULL ) goto write_ignore;
>>>>            vgic_lock_rank(v, rank, flags);
>>>>            tr = rank->ienable;
>>>>            vreg_reg32_setbits(&rank->ienable, r, info);
>>>> -        vgic_enable_irqs(v, (rank->ienable) & (~tr), rank->index);
>>>> +        if ( reg >= GICD_ISENABLERnE )
>>>> +            vgic_enable_irqs(v, (rank->ienable) & (~tr),
>>>> +                             EXT_RANK_IDX2NUM(rank->index));
>>>> +        else
>>>> +            vgic_enable_irqs(v, (rank->ienable) & (~tr), rank->index);
>>>
>>> ... you now have to keep both "if" the same. Unless we can have a
>>> version to avoid "ifs" everywhere (maybe using macros), I would rather
>>> create a separate funciton to handle eSPIs.
>>>
>>> Cheers,
>>>
>>
>> The main idea of V5 of this patch is to consolidate similar code and
>> keep the pairs of regular SPIs and their eSPI counterparts in the same
>> place to simplify any future modifications of these pairs. If
>> eSPI-specific registers are moved to a separate function, it would
>> result in code duplication. Additionally, I think it would be easier to
>> miss updating the code for one register of the SPI/eSPI pair while
>> modifying the code for the other..
> 
> I understand your reasoning, but in this case, we need to try to keep 
> the code as common as possible and reduce the number of ifs. Looking at 
> the patch again, we seem to often use "EXT_RANK_IDX2NUM(rank->index)"
> and this is why we have the second "if", for instance here. I think it 
> would be preferable if "index" store the proper value.
>

Actually, there are 4 specific cases where I need to use EXT_RANK_IDX2NUM:
vgic_enable_irqs, vgic_disable_irqs, vgic_set_irqs_pending, and 
vgic_check_inflight_irqs_pending. The reason I made this transformation 
is that these functions are generic and calculate the virq based on the 
rank number, e.g. vgic_check_inflight_irqs_pending():

unsigned int irq = i + 32 * rank;

As a result, I decided to introduce EXT_RANK_IDX2NUM with ifs rather 
than modifying very generic code that would also affect vGICv2 and be 
more difficult to upstream..

> An alternative would be to process the 3rd parameters separately.
> 
> The next big one to takle is:
> 
> if ( reg >= ... )
>     vgic_ext_rank_...(...)
> else
>     vgic_rank(...)
> 
> Ideally I would like to provide an helper that can figure out whether 
> this is an eSPI or not. Looking at the pattern, I think we would 
> introduce a new helper which rather than taking a relative offset take 
> the reg offset, the base for SPIs and the base for eSPIs.
> 
> Cheers,
> 

Hm, that's a good idea. I will try to implement this. I agree that it 
will reduce the boilerplate code.

Best regards,
Leonid

 


Rackspace

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