RfC: vfio: add vgpu edid support?

[Gerd Hoffmann]

  Hi,

> > Ideally qemu would also be able to update the edid blob at any time, and
> > the vgpu will notify the guest about it (probably by emulating a monitor
> > hotplug event).  The guest can react on qemu window resizing then and
> > adapt automatically, simliar to how it works with qxl and virtio-gpu.
> 
> What's the frequency for those edid update during resizing? Looks it's
> possible to bring hotplug storm that I'm not sure if all guest drivers
> for gvt has proper handling.

At most once per second.

The window resize typically creates a flood of the these events.  qemu
doesn't forward them to the guest as-is, but instead sets up a timer,
firing one second later.  The next event coming in just rearms the
timer.  When the timer goes off the guest is actually notified.

> > The guest and the vgpu should be able to handle "odd" non-standard
> > display resolutions like this (coming from random window resizing):
> > 
> >    Detailed mode: Clock 106.620 MHz, 477 mm x 330 mm
> >                   1212 1515 1551 1636 hborder 0
> >                    840  844  848  869 vborder 0
> >                   -hsync -vsync 
> >                   VertFreq: 74 Hz, HorFreq: 65171 Hz
> >
> 
> Some odd timing might not be supported, e.g can't get a sane PLL setting
> calculation for clock required. As gvt exposes a virtual display pipeline
> following hw definition, so guest driver still depend on sane output, I
> think that may just go wrong with arbitrary mode..

I've suspected that might become an issue.
What kind of restrictions exist for the clock?

> > +struct vfio_device_gfx_edid_set {
> > +	__u32 argsz;
> > +	__u32 flags;
> > +	/* in */
> > +	__u8  edid[256];
> > +};
> > +
> 
> I assume you have defined return value for the set too right? In case
> for driver can't handle or invalid edid blob, etc.

Just return -EINVAL then, as usual (but I can update the comment
explicitly saying so).

cheers,
  Gerd