On Tue, 29 May 2012 17:51:50 +0300 Alon Levy <al...@redhat.com> 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 <kra...@redhat.com> 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 >
