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

[Michael S. Tsirkin]

On Mon, Mar 17, 2014 at 02:36:37PM +1000, Dave Airlie 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.
> 
> Dave.

I think Paolo refers to a case where these events
arrive faster than guest can handle them.

As long as there's a single event like this,
it seems possible to avoid such under-runs by guest,
by first making a new buffer available, then processing
a used buffer.

If we want this extendable to multiple events,
make guest prepend an out buffer with a header, saying what kind of
event is expected in a given buffer.

Yes, config space is slow and should be avoided for
normal operation. I'm not sure how common this
specific operation is. For reporting guest errors
config space has some advantages as it can
be read even if driver/device communication
is completely wedged.

-- 
MST