Re: [Qemu-devel] [PATCH 3/3] hw/qxl: support client monitor configuration via device

[Alon Levy <alevy@redhat.com>]

> > Hi,
> > 
> > Sorry for top posting, but trying to summarize this thread here.
> > 
> > I must say I like Gerd's approach, as it unifies code paths mostly,
> > instead of having yet another interface where we do 2 way
> > capabilities
> > negotiation, with all the extra test matrix entries that would
> > entice
> > for full testing, we keep things simple.
> 
> So you are suggesting to send the message to both parties, and ignore
> it in the guest agent if it sees a qxl device.
s/device/drm device file/ - this is linux specific right now, for windows guests we would check for something else presumably (not interesting right now).

> That's the only way
> this works, since otherwise you need a handshake between spice and
> qxl:
> 
> server
> (1) receive VDAgentMonitorsConfig config
> (2) call qxl->client_monitors_config
> (3) wait for qxl->client_monitors_config_not_acked <-- after timeout?
> when do we decide interrupt wasn't cleared due to guest not
> supporting it, or due to not enough time having passed?
> (4a) if timeout, send VDAgentMonitorsConfig to agent
> (4b) else done
> 
> > 
> > So we would have:
> > 1) monitor config in rom space
> > 2) QXL_INTERRUPT_CLIENT_MONITORS_CONFIG to tell the guest it is
> > updated
> > 3) Some way to avoid a new monitor config arriving and the guest
> > being
> >     busy reading the previous race.
> > 4) The server will always update the monitor config in rom space
> > 5) If the guest has not requested
> > QXL_INTERRUPT_CLIENT_MONITORS_CONFIG
> >     and there is an agent the server will send the monitor info to
> >     the
> >     agent
> > 
> > Note an alternative to the handshake suggested is simply adding a
> > crc
> > to the monitor config block. If that fails we hit the the (rare)
> > race
> > and
> > the guest re-reads it.
> > 
> > Regards,
> > 
> > Hans
> > 
> > 
> 
>