Hi,
On 25/11/2025 12:03, Michal Orzel wrote:
Similar to other registers like ICPENDR and ICACTIVER, ignore the writes
instead of injecting fault into the guest and thus crashing it.
Sure... But you are potentially introducing an instability in the guest
OS which may be difficult to diagnose. So why is it better?
This was
already the case for extended registers prior to introducing GICV3_ESPI.
Why only the vGICv3?
Signed-off-by: Michal Orzel <[email protected]>
---
xen/arch/arm/vgic-v3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 8b1c8eef8024..33dfd13dccf1 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -887,7 +887,8 @@ static int __vgic_v3_distr_common_mmio_write(const char
*name, struct vcpu *v,
printk(XENLOG_G_ERR
"%pv: %s: unhandled word write %#"PRIregister" to
ISACTIVER%dE\n",
v, name, r, reg - GICD_ISACTIVERnE);
- return 0;
+
+ goto write_ignore;
I know we already use that for ICACTIVER. But this is against the
specification. We can't just ignore a guest asking to activate an interrupt.
The commit message really some details on why we want to do ignore the
write (IOW is this impacting an OS) and what's the consequence to ignore
the request?
case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
case VRANGE32(GICD_ICACTIVERnE, GICD_ICACTIVERnEN):
Cheers,
--
Julien Grall
