Re: [PATCH] xen/arm: acpi: Support memory reserve configuration table

[Leo Yan <leo.yan@xxxxxxxxxx>]

Hi Julien,

On Thu, Aug 25, 2022 at 01:59:06PM +0100, Julien Grall wrote:

[...]

> > Seems to me, to support para virtualization driver model (like virtio),
> > Dom0 needs to provide the device driver backend, and DomUs enables
> > the forend device drivers.  In this case, the most hardware interrupts
> > (SPIs) are routed to Dom0.
> 
> That's correct. Most of the shared interrupts will be routed to dom0.

Thanks for confirmation.

> > To support passthrough driver model (VFIO), Xen needs to configure the
> > hardware GICv3 to directly route hardware interrupt to the virtual CPU
> > interface.
> 
> Do you mean GICv4 rather than GICv3? In the latter, all the interrupts will
> be received in Xen and then routed to the domain by updating the LRs.

Thanks for clarification.

So GICv3 relies on hypervisor to set LR, and VM can use virtural
interface to response (ACK/EOI) the interrupt.  GICv4 can directly
forward the SPI to the CPU virtual interface (without hypervisor's
interfering).

> > But here I still cannot create the concept that how GIC RD tables play
> > roles to support the para virtualization or passthrough mode.
> 
> I am not sure what you are actually asking. The pending tables are just
> memory you give to the GICv3 to record the state of the interrupts.

For more specific, Xen has its own RD pending table, and we can use
this pending table to set state for SGI/PPI/LPI for a specific CPU
interface.  Xen works as hypervisor, it saves and restores the pending
table according to switched in VM context, right?

On the other hand, what's the purpose for Linux kernel's GIC RD
pending table?  Is it only used for nested virtulisation?  I mean if
Linux kernel's GIC RD pending table is not used for the drivers in
Dom0 or DomU, then it's useless to pass it from the primary kernel to
secondary kernel; as result, we don't need to reserve the persistent
memory for the pending table in this case.

Thanks,
Leo