[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] libvirt<->QEMU interfaces for CPU models
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] libvirt<->QEMU interfaces for CPU models |
Date: |
Mon, 4 Mar 2013 10:33:20 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Mar 01, 2013 at 03:58:18PM -0300, Eduardo Habkost wrote:
> On Fri, Mar 01, 2013 at 07:31:46PM +0100, Andreas Färber wrote:
> > Am 01.03.2013 14:12, schrieb Jiri Denemark:
> > > On Thu, Feb 21, 2013 at 11:58:18 -0300, Eduardo Habkost wrote:
> > >> = Listing CPU models =
> > >>
> > >> Requirement: libvirt needs to know which CPU models are available to be
> > >> used
> > >> with the "-cpu" option.
> > >>
> > >> Current problem: libvirt relies on help output parsing for that.
> >
> > query-cpu-definitions is the QMP command to retrieve values compatible
> > with -cpu.
> >
> > And if libvirt is not using it, I really don't understand why the work
> > of maintaining this crappy interface has been pushed onto us in the
> > first place? There is no reuse between -cpu ? and QMP implementations so
> > it's just extra work, there is no communicated or implemented way to
> > extend the arch_query_cpu_definitions() implementation to become more
> > usable for command line output implementation (e.g., associating a PVR
> > value with the model name for ppc) and, while we're at it, it uses
> > global functions plus a stub rather than a CPUState hook with a no-op
> > default implementation in qom/cpu.c...
>
> I have the same questions you have. :-)
>
> But my main complaint about query-cpu-definitions is not about the
> implementation: it's that the interface was introduced without taking
> into account the requirements of libvirt regarding CPU features. It was
> found to be not appropriate for what libvirt needs[1], but somehow it
> got applied anyway.
The requirement at the time we did this was just to have a straight
adaptation of the stuff libvirt parsed from -help, into QMP format.
The query-cpu-definitions command served that purpose fine. It was
expected that some of this may be sub-optimal in the long term. This
is fine - we can either extend the existing data, or introduce brand
new commands to deal with the problems. The key thing was just to get
100% into the QMP world for capabilities at that time, and then iterate
to improve things.
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 :|