Re: [PATCH v2 07/11] gunyah: msgq: Add Gunyah message queues

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

 





On 8/9/2022 4:29 AM, Marc Zyngier wrote:
On Mon, 08 Aug 2022 23:22:48 +0100,
Elliot Berman <quic_eberman@xxxxxxxxxxx> wrote:

In a future series, I'll add the support to load other virtual
machines. When running other virtual machines, additional gunyah
devices are needed for doorbells (e.g. to emulate interrupts for
paravirtualized devices) and to represent the vCPUs of that other
VM. Other gunyah devices are also possible, but those are the
immediate devices coming over the horizon.

Can you elaborate on this "doorbell" aspect? If you signal interrupts
to guests, they should be signalled as actual interrupts, not as some
hypervisor-specific events, as we rely on the interrupt semantics for
most things.

Or are you talking about injecting an interrupt from a guest into
another, the doorbell representing an interrupt source?


Doorbells can operate either of these modes:
 1. As simple interrupt sources. The doorbell sender makes a hypercall
    and an interrupt is raised on the receiver. The hypervisor can be
    configured to raise a specific SPI on the receiver VM and simply
    acknowledging the SPI is enough to clear the interrupt assert. No
    hypervisor-specific code is needed on the receiver to handle these
    interrupts. This is the mode one would expect to use for
    paravirtualized devices.
 2. As hypervisor-specific events which must be acknowledged using
    hypercalls. We aren't currently using this advanced use-case and no
    plans currently to post these. However, I can try to briefly
    explain: These doorbells can operate on a bitfield and the sender
    can assert flags on the bitmask; the receiver can decide which bits
    should trigger the interrupt and which SPI the doorbell "runs" on.
    The "user story" for this doorbell is to support multiple sender
    using the same doorbell object. Each sender has a few designated
    bits they should set. The receiver can choose which events it wants
    an interrupt to be raised for and then can process all the pending
    events. To re-iterate, we don't have an interesting use-case for
    this yet, so don't plan on post patches for this second mode of
    doorbell.


Thanks,

	M.




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux