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

[Avi Kivity <avi@redhat.com>]

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