Re: [PATCH] Inter-VM shared memory PCI device

Avi Kivity
2010-03-09T17:28:13Z

On 03/09/2010 05:27 PM, Cam Macdonell wrote:
>
>>
>>> Registers are used
>>> for synchronization between guests sharing the same memory object when
>>> interrupts are supported (this requires using the shared memory server).
>>>
>>>
>> How does the driver detect whether interrupts are supported or not?
>>
> At the moment, the VM ID is set to -1 if interrupts aren't supported,
> but that may not be the clearest way to do things. With UIO is there
> a way to detect if the interrupt pin is on?
>

I suggest not designing the device to uio. Make it a good
guest-independent device, and if uio doesn't fit it, change it.

Why not support interrupts unconditionally? Is the device useful
without interrupts?

>>> The Doorbell register is 16-bits, but is treated as two 8-bit values. The
>>> upper 8-bits are used for the destination VM ID. The lower 8-bits are the
>>> value which will be written to the destination VM and what the guest
>>> status
>>> register will be set to when the interrupt is trigger is the destination
>>> guest.
>>>
>>>
>> What happens when two interrupts are sent back-to-back to the same guest?
>> Will the first status value be lost?
>>
> Right now, it would be. I believe that eventfd has a counting
> semaphore option, that could prevent loss of status (but limits what
> the status could be).
>

It only counts the number of interrupts (and kvm will coalesce them anyway).

> My understanding of uio_pci interrupt handling
> is fairly new, but we could have the uio driver store the interrupt
> statuses to avoid losing them.
>

There's nowhere to store them if we use ioeventfd/irqfd. I think it's
both easier and more efficient to leave this to the application (to
store into shared memory).

--

error compiling committee.c: too many arguments to function