On Mon, Mar 17, 2014 at 2:36 PM, Dave Airlie <airl...@gmail.com> wrote: > On Thu, Mar 13, 2014 at 8:40 PM, Paolo Bonzini <pbonz...@redhat.com> 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.