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

[Luiz Capitulino]

On Tue, 29 May 2012 17:51:50 +0300
Alon Levy <address@hidden> wrote:

> 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:

Do you expect mngt apps to use that info or is it just for debugging? If it's
the latter, then maybe we could add query-qxl as gen=no and declare it unstable.

>  * 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.

What kind of error report?

> 
> 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
>