qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 0/2] ARM: add QMP command to query GIC versi


From: Andrew Jones
Subject: Re: [Qemu-devel] [RFC PATCH 0/2] ARM: add QMP command to query GIC version
Date: Thu, 18 Feb 2016 17:52:08 +0100
User-agent: Mutt/1.5.23.1 (2014-03-12)

On Thu, Feb 18, 2016 at 12:40:56PM +0800, Peter Xu wrote:
> On Mon, Feb 15, 2016 at 03:22:05PM +0000, Daniel P. Berrange wrote:
> > On Mon, Feb 15, 2016 at 04:08:33PM +0100, Markus Armbruster wrote:
> > > Peter Xu <address@hidden> writes:
> > > 
> > > > On Mon, Feb 15, 2016 at 10:52:01AM +0100, Markus Armbruster wrote:
> > > >> Peter Xu <address@hidden> writes:
> > > >> 
> > > >> > For ARM platform, we still do not have any interface to query
> > > >> > whether current QEMU/host support specific GIC version. This
> > > >> > patchset is trying to add one QMP interface for that. By querying
> > > >> > the GIC capability using the new interface, one should know exactly
> > > >> > what GIC version(s) the platform will support. The capability bits
> > > >> > will be decided by both QEMU and host kernel.
> > > >> >
> > > >> > The current patchset only provides interface for review. Its handler
> > > >> > is a fake one which returns empty always.
> > > >> >
> > > >> > The command interface I am planning to add is something like this:
> > > >> >
> > > >> > -> { "execute": "query-gic-capability" }
> > > >> > <- { "return": [ "gicv2", "gicv2-kvm", "gicv3-kvm" ] }
> > > >> >
> > > >> > Currently, all the possible supported GIC versions are:
> > > >> >
> > > >> > - gicv2:      GIC version 2 without kernel IRQ chip
> > > >> > - gicv2-kvm:  GIC version 2 with kernel IRQ chip
> > > >> > - gicv3:      GIC version 3 without kernel IRQ chip (not supported)
> > > >> > - gicv3-kvm:  GIC version 3 with kernel IRQ chip
> > > >> >
> > > >> > Since "gicv3" is still not supported (to use GICv3, kernel irqchip
> > > >> > support is required for now, which corresponds to "gicv3-kvm"),
> > > >> > currently the maximum superset of the result should be:
> > > >> >
> > > >> > ["gicv2", "gicv2-kvm", "gicv3-kvm"]
> > > >> >
> > > >> > Please help review whether the interface suits our need, also please
> > > >> > point out any error I have made.
> > > >> 
> > > >> Adding ad hoc queries as we go won't scale.  Is there really no generic
> > > >> way to get this information, e.g. with qom-get?
> > > >
> > > > Haven't used "qom-get" before, but it seems to fetch one property
> > > > for a specific object. If so, will it be strange to hide some
> > > > capability bits into every GIC objects (though there is possibly
> > > > one object)?
> > > 
> > > Pardon my ignorance...  what are these "GIC objects"?
> > > 
> > > What exactly is the "GIC type", and how would the result of
> > > query-gic-capability be used?
> > > 
> > > > I agree that we should keep the interface as simple as
> > > > possible. I see that there are already commands that works just like
> > > > this one, which is to query some capabilities from QEMU, like:
> > > >
> > > > - query-dump-guest-memory-capability
> > > > - query-migrate-capabilities
> > > 
> > > I'm not saying we must not add another ad hoc query.  I'm trying to
> > > figure out whether existing generic infrastructure can serve, or be
> > > adapted to serve.  Once we establish the answer is "no" or "badly", I'm
> > > willing to consider the ad hoc query.
> > 
> > Looking at this from the POV of solving the generic problem, what we
> > have here is an object with an integer property, for which only certain
> > values are permitted based on what host kernel/hardware we're runing
> > on.
> > 
> > So to solve this generically, we would need a way to provide information
> > in QOM as to what permitted values are for any given property. This would
> > make sense for at least bool, int and enum properties, since they can all
> > potentially have scenarios where the possible range of values is greater
> > than the currently permissible range of values.
> 
> Is this work on any of our todo list (or anyone has started the
> prototyping)?
> 
> It seems reasonable to provide such a generic interface, rather than
> adding a "query-gic-capability" for GIC versions only. The problem
> is that, I am not sure how eagerly we are wanting this GIC
> interface, and when will this framework be there in QOM.

We want it eagerly :-) This type of a rabbit hole is likely why Daniel
was suggesting we do more in libvirt. I'm still not sure we want to
probe both kvm and qemu from libvirt though, so I'm still in favor of
an improved qemu probing method being worked out.

I don't know what the policy is for deprecating QMP commands, but I
wonder if we can't introduce a QMP command now, and then, after working
out the QOM extensions, we could shift to it, deprecating this QMP
command and any others that would no longer be needed.

Thanks,
drew


> 
> Thanks.
> Peter
> 
> > 
> > Regards,
> > Daniel
> > -- 
> > |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ 
> > :|
> > |: http://libvirt.org              -o-             http://virt-manager.org 
> > :|
> > |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ 
> > :|
> > |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc 
> > :|
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]