All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Larsson <alexl@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Alon Levy <alevy@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] qxl: Export "mode" as a property
Date: Tue, 20 Nov 2012 11:30:24 +0100	[thread overview]
Message-ID: <1353407424.2180.44.camel@fatty> (raw)
In-Reply-To: <50AB58AA.6060303@redhat.com>

On tis, 2012-11-20 at 11:17 +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > I'm working on a kind of "troubleshooting log" option for gnome-boxes
> > which wants to record all these kinds of data so that a helpdesk or a
> > developer can help figuring out a problem with a guest.
> 
> Understood.
> 
> > Knowing if a qxl
> > driver is in use is an important piece of information. Additionally it
> > would be very nice if the driver could report a version string that I
> > could query (same for virtio driver, etc).
> 
> Guest driver version information isn't available.

I know that, but it would be possible to add code to the driver to
register a version string.

> For QXL we could track which features are in use by the driver (i.e.
> whenever it uses sync/async io ports, ...) which might be good enougth
> for trouble shooting.

Might be useful for qxl developers, but not very useful to e.g. a
helpdesk employee trying to solve an issue for a user, as its kinda
low-level. Having the version string would be very nice here.

> For virtio it should be likewise easy to figure which device features
> the guest has activated.
> 
> If you also wanna have this for non-qxl devices (which makes sense
> indeed) going the "info spice" route doesn't make that much sense
> though.  It is probably more useful to add an (optional) "report device
> state" callback to devices which then returns this info in some useful
> format (qdict?), then wind this up as monitor command.

Sure, that would work too, as long as i can enumerate the devices and
get the data in a machine parsable format. Properties are already that,
although I realize that mixing configuration and monitoring in the same
set might be problematic.

  reply	other threads:[~2012-11-20 10:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-19 13:11 [Qemu-devel] [PATCH] qxl: Export "mode" as a property Alexander Larsson
2012-11-20  7:50 ` Gerd Hoffmann
2012-11-20  9:07   ` Daniel P. Berrange
2012-11-20  9:15     ` Gerd Hoffmann
2012-11-20  9:35       ` Alexander Larsson
2012-11-20 10:17         ` Gerd Hoffmann
2012-11-20 10:30           ` Alexander Larsson [this message]
2012-11-20 10:53             ` Gerd Hoffmann
2012-11-20 11:41               ` Alexander Larsson
2012-11-20  9:49       ` Alon Levy
2012-11-20  9:48   ` Markus Armbruster
2012-11-20  9:51     ` Alexander Larsson
2012-11-20 10:28     ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1353407424.2180.44.camel@fatty \
    --to=alexl@redhat.com \
    --cc=alevy@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.