[Spice-devel] [spice-protocol PATCH v2 0.12.2 1/2] qxl_dev.h: add client monitors configuration notification to guest

[Alon Levy]

> Hi,
> 
> On 09/11/2012 04:35 PM, Alon Levy wrote:
> > So far we have used the agent to notify the guest of a request to
> > change
> > the monitors configurations (heads) on the qxl device. This patch
> > introduces
> > a new interrupt and new fields in the qxl rom to notify the guest
> > about
> > a new request, similarly to how physical hardware notifies the
> > driver.
> >
> > To avoid overwriting the rom while the guest is reading it there is
> > a
> > client_monitors_config_updating field in ROM. The update protocol
> > is:
> >
> > qemu:
> >    (1) set QXLRom::client_monitors_config_updating
> >    (2) fill QXLRom::client_monitors_config
> >    (3) raise QXL_INTERRUPT_CLIENT_MONITORS_CONFIG
> >    (4) clear QXLRom::client_monitors_config_updating
> >
> > guest:
> >    (1) clear QXL_INTERRUPT_CLIENT_MONITORS_CONFIG bit in irq status
> >    (2) wait until QXLRom::client_monitors_config_updating is clear
> >    (3) parse QXLRom::client_monitors_config
> >    (4) check that QXLRom::client_monitors_Config_updating is clear
> >        (a) when set, goto (1)
> >    (5) check QXL_INTERRUPT_CLIENT_MONITORS_CONFIG bit in irq status
> >        (a) when set, goto (1)
> >        (b) when clear we are done
> >
> 
> This seems very complicated how about:
> 
> qemu:
>     (1) fill QXLRom::client_monitors_config, including a crc32 of the
>     data
>     (2) raise QXL_INTERRUPT_CLIENT_MONITORS_CONFIG
> 
> guest on interrupt:
>     (1) clear QXL_INTERRUPT_CLIENT_MONITORS_CONFIG bit in irq status
>     (2) read QXLRom::client_monitors_config
>     (3) (verify-crc)? done : goto 2
> 
> That seems more straight-forward to me.

Requires crc computing code in qemu and the guest. I know there is such in the kernel. I guess it's fine. It also has the chance of a mistake, I can let that slide I guess..

But more importantly I think I still need to change the protocol. I still need to know if the guest supports the client_monitors_config before issuing it, to take care of the case of a VDAgentMonitorsConfig arriving in multiple chunks, and for that I think one of:

 QXLInterface::client_monit-rs_config_supported()

pro: straightforward
con: add such for each cap? might as well add the guest_capabilities I introduced before, only this time set this cap from qemu instead of via a guest io (and don't introduce that guest io since we won't need it

alternative, reuse client_monitors_config, but have a NULL parameter just check and return without actually sending a message
pro: no extra api
con: abuse of a function

What do you think?

> 
> Regards,
> 
> Hans
>