Re: [Qemu-devel] [PATCH 3/4] virtio-gpu: v0.3 of the virtio based GPU code.

[Dave Airlie]

On Mon, Mar 17, 2014 at 2:36 PM, Dave Airlie <address@hidden> wrote:
> On Thu, Mar 13, 2014 at 8:40 PM, Paolo Bonzini <address@hidden> wrote:
>> Il 12/03/2014 21:26, Michael S. Tsirkin ha scritto:
>>>>
>>>> +Event queue:
>>>> +The only current event passed is a message to denote the host
>>>> +wants to update the layout of the screens. It contains the same
>>>> +info as the response to VIRTGPU_CMD_GET_DISPLAY_INFO.
>>
>>
>> I wonder if an event queue is the best mechanism if you can get the same
>> info from a command anyway.  For virtio-scsi I used a queue because I needed
>> to specify which target or LUN the event applied to, but here you do not
>> need it and a queue is susceptible to dropped events.
>>
>> Perhaps a configuration field is better, like this:
>>
>>     u32 events_read;
>>     u32 events_clear;
>>
>> A new event sets a bit in events_read and generates a configuration change
>> interrupt.  The guest should never write to events_read.
>>
>> Writing to events_clear has the side effect of the device doing "events_read
>> &= ~events_clear".  We cannot have R/W1C fields in virtio, but this
>> approximation is good enough.
>>
>> When the guest receives a configuration change interrupt, it reads
>> event_read.  If it is nonzero, it writes the same value it read to
>> events_clear, and sends the necessary commands to the card in order to
>> retrieve the event data.  It can then read again event_read, and loop if it
>> is again nonzero.
>>
>
> I steered away from using config space for anything for the normal
> operation of the GPU after looking at overheads and hearing from S390
> people that config space has some special properties on their hw,
>
> The number of these events should be small in a running system, and
> I'm not sure how we'd lose one.

Oh I was also going to use this queue to report HW error events from
the guest to the host,

like if the guest tries an illegal operation,

Dave.