From: Oleksandr Tyshchenko <olekstysh@gmail.com>
To: Leonid Komarianskyi <Leonid_Komarianskyi@epam.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Julien Grall <julien@xen.org>,
Bertrand Marquis <bertrand.marquis@arm.com>,
Michal Orzel <michal.orzel@amd.com>,
Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH v3 10/11] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers
Date: Wed, 27 Aug 2025 16:44:23 +0300 [thread overview]
Message-ID: <7b0e2df4-9666-4f7b-9ada-9f1000200fd3@gmail.com> (raw)
In-Reply-To: <d71bd33e-ec09-47e5-af68-b8a79c78971d@epam.com>
On 27.08.25 14:13, Leonid Komarianskyi wrote:
> Hello Oleksandr,
Hello Leonid
>
> Thank you for your close review.
>
> On 26.08.25 22:57, Oleksandr Tyshchenko wrote:
>>
>>
>> On 26.08.25 17:05, Leonid Komarianskyi wrote:
>>
>> Hello Leonid
>>
>>
>>> Implemented support for GICv3.1 extended SPI registers for vGICv3,
>>> allowing the emulation of eSPI-specific behavior for guest domains.
>>> The implementation includes read and write emulation for eSPI-related
>>> registers (e.g., GICD_ISENABLERnE, GICD_IROUTERnE, and others),
>>> following a similar approach to the handling of regular SPIs.
>>>
>>> The eSPI registers, previously located in reserved address ranges,
>>> are now adjusted to support MMIO read and write operations correctly
>>> when CONFIG_GICV3_ESPI is enabled.
>>>
>>> The availability of eSPIs and the number of emulated extended SPIs
>>> for guest domains is reported by setting the appropriate bits in the
>>> GICD_TYPER register, based on the number of eSPIs requested by the
>>> domain and supported by the hardware. In cases where the configuration
>>> option is disabled, the hardware does not support eSPIs, or the domain
>>> does not request such interrupts, the functionality remains unchanged.
>>>
>>> Signed-off-by: Leonid Komarianskyi <leonid_komarianskyi@epam.com>
>>>
>>> ---
>>> Changes in V2:
>>> - add missing rank index conversion for pending and inflight irqs
>>>
>>> Changes in V3:
>>> - changed vgic_store_irouter parameters - instead of offset virq is
>>> used, to remove the additional bool espi parameter and simplify
>>> checks. Also, adjusted parameters for regular SPI. Since the offset
>>> parameter was used only for calculating virq number and then reused
>>> for
>>> finding rank offset, it will not affect functionality.
>>> - fixed formatting for goto lables - added newlines after condition
>>> - fixed logs for GICD_ISACTIVERnE and GICD_ICACTIVERnE handlers
>>> - removed #ifdefs in 2 places where they were adjacent and could be
>>> merged
>>> ---
>>> xen/arch/arm/vgic-v3.c | 275 +++++++++++++++++++++++++++++++++++++++--
>>> 1 file changed, 266 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
>>> index 4369c55177..56c539bb1b 100644
>>> --- a/xen/arch/arm/vgic-v3.c
>>> +++ b/xen/arch/arm/vgic-v3.c
>>> @@ -111,13 +111,10 @@ static uint64_t vgic_fetch_irouter(struct
>>> vgic_irq_rank *rank,
>>> * Note the offset will be aligned to the appropriate boundary.
>>> */
>>> static void vgic_store_irouter(struct domain *d, struct
>>> vgic_irq_rank *rank,
>>> - unsigned int offset, uint64_t irouter)
>>> + unsigned int virq, uint64_t irouter)
>>> {
>>> struct vcpu *new_vcpu, *old_vcpu;
>>> - unsigned int virq;
>>> -
>>> - /* There is 1 vIRQ per IROUTER */
>>> - virq = offset / NR_BYTES_PER_IROUTER;
>>> + unsigned int offset;
>>> /*
>>> * The IROUTER0-31, used for SGIs/PPIs, are reserved and should
>>> @@ -685,6 +682,9 @@ static int __vgic_v3_distr_common_mmio_read(const
>>> char *name, struct vcpu *v,
>>> {
>>> case VRANGE32(GICD_IGROUPR, GICD_IGROUPRN):
>>> case VRANGE32(GICD_IGRPMODR, GICD_IGRPMODRN):
>>> +#ifdef CONFIG_GICV3_ESPI
>>> + case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN):
>>> +#endif
>>> /* We do not implement security extensions for guests, read
>>> zero */
>>> if ( dabt.size != DABT_WORD ) goto bad_width;
>>> goto read_as_zero;
>>> @@ -710,11 +710,19 @@ static int
>>> __vgic_v3_distr_common_mmio_read(const char *name, struct vcpu *v,
>>> /* Read the pending status of an IRQ via GICD/GICR is not
>>> supported */
>>> case VRANGE32(GICD_ISPENDR, GICD_ISPENDRN):
>>> case VRANGE32(GICD_ICPENDR, GICD_ICPENDRN):
>>> +#ifdef CONFIG_GICV3_ESPI
>>> + case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN):
>>> + case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN):
>>> +#endif
>>> goto read_as_zero;
>>> /* Read the active status of an IRQ via GICD/GICR is not
>>> supported */
>>> case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN):
>>> case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
>>> +#ifdef CONFIG_GICV3_ESPI
>>> + case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN):
>>> + case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN):
>>> +#endif
>>> goto read_as_zero;
>>> case VRANGE32(GICD_IPRIORITYR, GICD_IPRIORITYRN):
>>> @@ -752,6 +760,69 @@ static int __vgic_v3_distr_common_mmio_read(const
>>> char *name, struct vcpu *v,
>>> return 1;
>>> }
>>> +#ifdef CONFIG_GICV3_ESPI
>>> + case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN):
>>> + if ( dabt.size != DABT_WORD )
>>> + goto bad_width;
>>> + rank = vgic_ext_rank_offset(v, 1, reg - GICD_ISENABLERnE,
>>> DABT_WORD);
>>> + if ( rank == NULL )
>>> + goto read_as_zero;
>>> + vgic_lock_rank(v, rank, flags);
>>> + *r = vreg_reg32_extract(rank->ienable, info);
>>> + vgic_unlock_rank(v, rank, flags);
>>> + return 1;
>>> +
>>> + case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN):
>>> + if ( dabt.size != DABT_WORD )
>>> + goto bad_width;
>>> + rank = vgic_ext_rank_offset(v, 1, reg - GICD_ICENABLERnE,
>>> DABT_WORD);
>>> + if ( rank == NULL )
>>> + goto read_as_zero;
>>> + vgic_lock_rank(v, rank, flags);
>>> + *r = vreg_reg32_extract(rank->ienable, info);
>>> + vgic_unlock_rank(v, rank, flags);
>>> + return 1;
>>> +
>>> + case VRANGE32(GICD_IPRIORITYRnE, GICD_IPRIORITYRnEN):
>>> + {
>>> + uint32_t ipriorityr;
>>> + uint8_t rank_index;
>>> +
>>> + if ( dabt.size != DABT_BYTE && dabt.size != DABT_WORD )
>>> + goto bad_width;
>>> + rank = vgic_ext_rank_offset(v, 8, reg - GICD_IPRIORITYRnE,
>>> DABT_WORD);
>>> + if ( rank == NULL )
>>> + goto read_as_zero;
>>> + rank_index = REG_RANK_INDEX(8, reg - GICD_IPRIORITYRnE,
>>> DABT_WORD);
>>> +
>>> + vgic_lock_rank(v, rank, flags);
>>> + ipriorityr = ACCESS_ONCE(rank->ipriorityr[rank_index]);
>>> + vgic_unlock_rank(v, rank, flags);
>>> +
>>> + *r = vreg_reg32_extract(ipriorityr, info);
>>> +
>>> + return 1;
>>> + }
>>> +
>>> + case VRANGE32(GICD_ICFGRnE, GICD_ICFGRnEN):
>>> + {
>>> + uint32_t icfgr;
>>> +
>>> + if ( dabt.size != DABT_WORD )
>>> + goto bad_width;
>>> + rank = vgic_ext_rank_offset(v, 2, reg - GICD_ICFGRnE,
>>> DABT_WORD);
>>> + if ( rank == NULL )
>>> + goto read_as_zero;
>>> + vgic_lock_rank(v, rank, flags);
>>> + icfgr = rank->icfg[REG_RANK_INDEX(2, reg - GICD_ICFGRnE,
>>> DABT_WORD)];
>>> + vgic_unlock_rank(v, rank, flags);
>>> +
>>> + *r = vreg_reg32_extract(icfgr, info);
>>> +
>>> + return 1;
>>> + }
>>> +#endif
>>> +
>>> default:
>>> printk(XENLOG_G_ERR
>>> "%pv: %s: unhandled read r%d offset %#08x\n",
>>> @@ -782,6 +853,9 @@ 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):
>>> +#ifdef CONFIG_GICV3_ESPI
>>> + case VRANGE32(GICD_IGROUPRnE, GICD_IGROUPRnEN):
>>> +#endif
>>> /* We do not implement security extensions for guests, write
>>> ignore */
>>> goto write_ignore_32;
>>> @@ -871,6 +945,99 @@ static int
>>> __vgic_v3_distr_common_mmio_write(const char *name, struct vcpu *v,
>>> vgic_unlock_rank(v, rank, flags);
>>> return 1;
>>> +#ifdef CONFIG_GICV3_ESPI
>>> + case VRANGE32(GICD_ISENABLERnE, GICD_ISENABLERnEN):
>>> + if ( dabt.size != DABT_WORD )
>>> + goto bad_width;
>>> + rank = vgic_ext_rank_offset(v, 1, reg - GICD_ISENABLERnE,
>>> DABT_WORD);
>>> + 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),
>>> EXT_RANK_IDX2NUM(rank->index));
>>> + vgic_unlock_rank(v, rank, flags);
>>> + return 1;
>>> +
>>> + case VRANGE32(GICD_ICENABLERnE, GICD_ICENABLERnEN):
>>> + if ( dabt.size != DABT_WORD )
>>> + goto bad_width;
>>> + rank = vgic_ext_rank_offset(v, 1, reg - GICD_ICENABLERnE,
>>> DABT_WORD);
>>> + if ( rank == NULL )
>>> + goto write_ignore;
>>> + vgic_lock_rank(v, rank, flags);
>>> + tr = rank->ienable;
>>> + vreg_reg32_clearbits(&rank->ienable, r, info);
>>> + vgic_disable_irqs(v, (~rank->ienable) & tr,
>>> EXT_RANK_IDX2NUM(rank->index));
>>> + vgic_unlock_rank(v, rank, flags);
>>> + return 1;
>>> +
>>> + case VRANGE32(GICD_ISPENDRnE, GICD_ISPENDRnEN):
>>> + if ( dabt.size != DABT_WORD )
>>> + goto bad_width;
>>> + rank = vgic_ext_rank_offset(v, 1, reg - GICD_ISPENDRnE,
>>> DABT_WORD);
>>> + if ( rank == NULL )
>>> + goto write_ignore;
>>> +
>>> + vgic_set_irqs_pending(v, r, EXT_RANK_IDX2NUM(rank->index));
>>> +
>>> + return 1;
>>> +
>>> + case VRANGE32(GICD_ICPENDRnE, GICD_ICPENDRnEN):
>>> + if ( dabt.size != DABT_WORD )
>>> + goto bad_width;
>>> + rank = vgic_ext_rank_offset(v, 1, reg - GICD_ICPENDRnE,
>>> DABT_WORD);
>>> + if ( rank == NULL )
>>> + goto write_ignore;
>>> +
>>> + vgic_check_inflight_irqs_pending(v, EXT_RANK_IDX2NUM(rank-
>>>> index), r);
>>> +
>>> + goto write_ignore;
>>> + case VRANGE32(GICD_ISACTIVERnE, GICD_ISACTIVERnEN):
>>> + if ( dabt.size != DABT_WORD )
>>> + goto bad_width;
>>> + printk(XENLOG_G_ERR
>>> + "%pv: %s: unhandled word write %#"PRIregister" to
>>> ISACTIVER%dE\n",
>>> + v, name, r, reg - GICD_ISACTIVERnE);
>>> + return 0;
>>
>> Guest write access to GICD_ISACTIVER<n>E will lead to abort. But, I know
>> you just repeated the logic for regular GICD_ISACTIVER<n>.
>>
>>
>
> Could you please clarify the scenario in which it leads to an abort?
> Since it is actually a stub case, it should just print an error message
> and that's it..
"return 0;" will lead to injecting a fault into the guest.
Do you mean that, in this case, we need to goto
> write_ignore_32 label instead of returning 0?
My comment was not a direct request to change anything, but rather
thinking out loud.
Unfortunally, I cannot answer why regular GICD_ISACTIVER<n> is emulated
in that way, but perhaps the injecting fault into the guest is the
lesser evil than emulating it incorrectly...
Interestingly, for GICv2 we have a slighly relaxed version; it looks
like writing 0 will not cause an abort and will be WI.
25f9e80201f3688e0c4d5c4e43e4b6143b441c52
xen/arm: Ignore write to GICD_ISACTIVERn registers (vgic-v2)
Now, with the introduction of extended GICD_ISACTIVER<n>E you retained
the logic. One thing that needs mentioning is that before your series,
guest write access to extended GICD_ISACTIVER<n>E would be WI, but
with your series and CONFIG_GICV3_ESPI=y it will be an abort even
if running on GIC3 HW where eSPI is not supported.
At least, I would mention that in the patch description.
>
>>> +
>>> + case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN):
>>> + printk(XENLOG_G_ERR
>>> + "%pv: %s: unhandled word write %#"PRIregister" to
>>> ICACTIVER%dE\n",
>>> + v, name, r, reg - GICD_ICACTIVER);
>>
>> s/GICD_ICACTIVER/GICD_ICACTIVERnE
>>
>>
>
> I will fix that in V4.
>
>>> + goto write_ignore_32;
[snip]
next prev parent reply other threads:[~2025-08-27 13:44 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-26 14:05 [PATCH v3 00/11] Subject: [PATCH v3 00/11] Introduce eSPI support Leonid Komarianskyi
2025-08-26 14:05 ` [PATCH v3 02/11] xen/arm: gic: implement helper functions for INTID checks Leonid Komarianskyi
2025-08-26 19:49 ` Volodymyr Babchuk
2025-08-26 19:53 ` Volodymyr Babchuk
2025-08-26 14:05 ` [PATCH v3 01/11] xen/arm: gicv3: refactor obtaining GIC addresses for common operations Leonid Komarianskyi
2025-08-26 19:47 ` Volodymyr Babchuk
2025-08-26 14:05 ` [PATCH v3 04/11] xen/arm/irq: add handling for IRQs in the eSPI range Leonid Komarianskyi
2025-08-26 20:16 ` Volodymyr Babchuk
2025-08-27 6:35 ` Oleksandr Tyshchenko
2025-08-27 13:22 ` Leonid Komarianskyi
2025-08-26 14:05 ` [PATCH v3 05/11] xen/arm: gicv3: implement handling of GICv3.1 eSPI Leonid Komarianskyi
2025-08-26 22:25 ` Volodymyr Babchuk
2025-08-27 9:56 ` Leonid Komarianskyi
2025-08-27 10:25 ` Oleksandr Tyshchenko
2025-08-27 13:38 ` Leonid Komarianskyi
2025-08-27 13:57 ` Oleksandr Tyshchenko
2025-08-26 14:05 ` [PATCH v3 03/11] xen/arm: vgic: implement helper functions for virq checks Leonid Komarianskyi
2025-08-26 20:02 ` Volodymyr Babchuk
2025-08-27 8:25 ` Leonid Komarianskyi
2025-08-26 14:05 ` [PATCH v3 06/11] xen/arm/irq: allow eSPI processing in the do_IRQ function Leonid Komarianskyi
2025-08-26 22:30 ` Volodymyr Babchuk
2025-08-27 10:00 ` Leonid Komarianskyi
2025-08-26 14:05 ` [PATCH v3 09/11] xen/arm: domain_build/dom0less-build: adjust domains config to support eSPIs Leonid Komarianskyi
2025-08-26 23:08 ` Volodymyr Babchuk
2025-08-27 10:25 ` Leonid Komarianskyi
2025-08-27 12:01 ` Oleksandr Tyshchenko
2025-08-27 13:47 ` Leonid Komarianskyi
2025-08-27 15:01 ` Leonid Komarianskyi
2025-08-26 14:05 ` [PATCH v3 07/11] xen/arm: gicv3: modify ICH_LR_PHYSICAL_MASK to allow eSPI processing Leonid Komarianskyi
2025-08-26 22:40 ` Volodymyr Babchuk
2025-08-26 14:05 ` [PATCH v3 08/11] xen/arm: vgic: add resource management for extended SPIs Leonid Komarianskyi
2025-08-26 23:00 ` Volodymyr Babchuk
2025-08-27 10:11 ` Leonid Komarianskyi
2025-08-26 14:05 ` [PATCH v3 11/11] CHANGELOG.md: add mention of GICv3.1 eSPI support Leonid Komarianskyi
2025-08-28 13:37 ` Oleksii Kurochko
2025-08-28 16:45 ` Leonid Komarianskyi
2025-08-26 14:05 ` [PATCH v3 10/11] xen/arm: vgic-v3: add emulation of GICv3.1 eSPI registers Leonid Komarianskyi
2025-08-26 19:57 ` Oleksandr Tyshchenko
2025-08-27 11:13 ` Leonid Komarianskyi
2025-08-27 13:44 ` Oleksandr Tyshchenko [this message]
2025-08-27 14:41 ` Leonid Komarianskyi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7b0e2df4-9666-4f7b-9ada-9f1000200fd3@gmail.com \
--to=olekstysh@gmail.com \
--cc=Leonid_Komarianskyi@epam.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=bertrand.marquis@arm.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.