Re: [PATCH v5 4/5] Inter-VM shared memory PCI device

[Avi Kivity <avi@redhat.com>]

On 05/11/2010 02:17 AM, Cam Macdonell wrote:
> On Mon, May 10, 2010 at 5:59 AM, Avi Kivity<avi@redhat.com>  wrote:
>    
>> On 04/21/2010 08:53 PM, Cam Macdonell wrote:
>>      
>>> Support an inter-vm shared memory device that maps a shared-memory object
>>> as a
>>> PCI device in the guest.  This patch also supports interrupts between
>>> guest by
>>> communicating over a unix domain socket.  This patch applies to the
>>> qemu-kvm
>>> repository.
>>>
>>>      -device ivshmem,size=<size in format accepted by -m>[,shm=<shm name>]
>>>
>>> Interrupts are supported between multiple VMs by using a shared memory
>>> server
>>> by using a chardev socket.
>>>
>>>      -device ivshmem,size=<size in format accepted by -m>[,shm=<shm name>]
>>>                      [,chardev=<id>][,msi=on][,irqfd=on][,vectors=n]
>>>      -chardev socket,path=<path>,id=<id>
>>>
>>> (shared memory server is qemu.git/contrib/ivshmem-server)
>>>
>>> Sample programs and init scripts are in a git repo here:
>>>
>>>
>>> +typedef struct EventfdEntry {
>>> +    PCIDevice *pdev;
>>> +    int vector;
>>> +} EventfdEntry;
>>> +
>>> +typedef struct IVShmemState {
>>> +    PCIDevice dev;
>>> +    uint32_t intrmask;
>>> +    uint32_t intrstatus;
>>> +    uint32_t doorbell;
>>> +
>>> +    CharDriverState * chr;
>>> +    CharDriverState ** eventfd_chr;
>>> +    int ivshmem_mmio_io_addr;
>>> +
>>> +    pcibus_t mmio_addr;
>>> +    unsigned long ivshmem_offset;
>>> +    uint64_t ivshmem_size; /* size of shared memory region */
>>> +    int shm_fd; /* shared memory file descriptor */
>>> +
>>> +    int nr_allocated_vms;
>>> +    /* array of eventfds for each guest */
>>> +    int ** eventfds;
>>> +    /* keep track of # of eventfds for each guest*/
>>> +    int * eventfds_posn_count;
>>>
>>>        
>> More readable:
>>
>>   typedef struct Peer {
>>       int nb_eventfds;
>>       int *eventfds;
>>   } Peer;
>>   int nb_peers;
>>   Peer *peers;
>>
>> Does eventfd_chr need to be there as well?
>>      
> No it does not, eventfd_chr store character devices for receiving
> interrupts when irqfd is not available, so we only them for this
> guest, not for our peers.
>    

Ok.

>> Does this need to be part of the state?
>>      
> They are because they're passed in as qdev properties from the
> command-line so I thought they needed to be in the state struct to be
> assigned via DEFINE_PROP_...
>    

Well I'm not q-ualified to comment on qdev, so I'm fine either way with 
this.

-- 
error compiling committee.c: too many arguments to function