[Qemu-devel] Re: [PATCH v4 1/3] Device specification for shared memory PCI device

[Cam Macdonell]

On Mon, Apr 12, 2010 at 3:34 PM, Avi Kivity <address@hidden> wrote:
> On 04/08/2010 01:51 AM, Cam Macdonell wrote:
>
> (sorry about the late review)
>
>> +
>> +Regular Interrupts
>> +------------------
>> +
>> +If regular interrupts are used (due to either a guest not supporting MSI
>> or the
>> +user specifying not to use them on startup) then the value written to the
>> lower
>> +16-bits of the Doorbell register results is arbitrary and will trigger an
>> +interrupt in the destination guest.
>>
>
> Does the value written show up in the status register?  If yes, it can get
> overwritten by other interrupts.  If not, the lower 16 bits should be
> reserved to the value 1 for future expansion.  Basically it means that the
> pci interrupt is equivalent to to vector 1.

The status register is only 1 or 0.  I've made it so 1 is the only
value written to trigger an interrupt.

>
>> +
>> +An interrupt is also generated when a new guest accesses the shared
>> memory
>> +region.  A status of (2^32 - 1) indicates that a new guest has joined.
>>
>
> Suggest making this a bitfield, define bit 0 as 'at least some other machine
> has signalled you' and bit 1 as 'at least one other machine has joined'.
>
>> +
>> +Message Signalled Interrupts
>> +----------------------------
>> +
>> +A ivshmem device may support multiple MSI vectors.  If so, the lower
>> 16-bits
>> +written to the Doorbell register must be between 1 and the maximum number
>> of
>> +vectors the guest supports.  The lower 16 bits written to the doorbell is
>> the
>> +MSI vector that will be raised in the destination guest.  The number of
>> MSI
>> +vectors can vary but it is set when the VM is started, however vector 0
>> is
>> +used to notify that a new guest has joined.  Guests should not use vector
>> 0 for
>> +any other purpose.
>>
>
> Come to think about it, the guest has joined is actually pointless.  Since
> it hasn't initialized yet you can't talk to it.  So it's best to leave it
> completely to the application, which can initialize shared memory and start
> sending interrupts.  An application defined protocol can handle joining.

Good point.

> How is initialization performed?  I guess we can define memory to start
> zeroed and let participants compete to acquire a lock.

No initialization of the memory occurs presently.

With interrupts the shared memory server could zero the memory.
Without the server (non-interrupt case) the guests can try and open
the shared memory with O_EXCL first and zero the memory if it
succeeds.  If O_EXCL fails, then guest would open without O_EXCL and
not initialize.

>
> Need to document the mask register.

Currently only applies with regular interrupts.  Since the status
register is only 0 or 1, then only the first bit has any affect.  I'll
add this to the spec.

>
> Do we want an interrupt on a guest leaving?  Let's not complicate things.

Probably not if we don't have one on join.

Cam