Re: [Qemu-devel] [PATCH v2] hmp/qxl: info spice: add qxl info

[Alon Levy]

On Tue, May 29, 2012 at 10:38:20AM -0300, Luiz Capitulino wrote:
> On Tue, 29 May 2012 09:25:40 +0200
> Gerd Hoffmann <address@hidden> wrote:
> 
> >   Hi,
> > 
> > >> How would that work? I have QXLInfo that only makes sense when the
> > >> information is about a qxl device. Can't have opaque data in a QMP
> > >> response, so would this be a "info display qxl" "info display cirrus"
> > >> etc. or "info qxl"?
> > > 
> > > You could show what's available and/or being used currently.
> > 
> > I think (Alon, correct me if I'm wrong) the use case is being able to
> > figure whenever the guest drivers are installed and active.
> 
> Alon, can you confirm this? I'm still not clear on the use-case.
> 
> The two points I'm wondering are 1. If this is really tied to spice (and thus
> this info should be part of query-spice) and now 2. if the use case above
> really pertains to QMP.
> 
> I've talked to someone in the past about having a way to get information about
> guest drivers statuses and the conclusion was that the guest-agent agent was
> better suited for that.

The information I'm suggesting to expose is state of the guest as seen
from device pov:
 * guest_bug - this indicates that the qxl device has been instructed to
  do something illegal that it has ignored, and until a reset from the
  guest, (QXL_RESET io write), that would presumably indicate a restart
  of the guest driver, we would like to ignore the guest from now on.
  This information would be helpful for error report.
 * mode - this is another indication of presence or lack of a guest
  driver. This time more straight forward - if a certain IO is issued
  (QXL_CREATE_PRIMARY) then the driver is in native mode. If another IO
  (SET_MODE) we are in compat mode. If anything to change back to vga
  happens (vga io read/write), we are back in vga, and if a
  DESTROY_SURFACE happens we are in undefined mode. This status would be
  helpful for error reporting as well.

Since both pieces of information already exist in the qemu side, there
is no need to introduce an agent to retrieve them. They are easy to
retrive with existing management (libvirt/vdsm can do random monitor
commands iirc).

Alon