On Thu, 15 May 2014 11:03:49 -0300
Eduardo Habkost <ehabkost(a)redhat.com> wrote:
On Thu, May 15, 2014 at 03:48:16PM +0200, Igor Mammedov wrote:
> On Thu, 15 May 2014 10:07:51 -0300
> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>
> > On Thu, May 15, 2014 at 02:35:01PM +0200, Igor Mammedov wrote:
> > > On Tue, 06 May 2014 22:29:24 +0200
> > > Andreas Färber <afaerber(a)suse.de> wrote:
> > >
> > > > Am 06.05.2014 22:19, schrieb Eduardo Habkost:
> > > > > On Tue, May 06, 2014 at 10:01:11PM +0200, Igor Mammedov wrote:
> > > > >> On Tue, 6 May 2014 11:42:56 -0300
> > > > >> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> > > > >>> On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov
wrote:
> > > > >>>> On Fri, 2 May 2014 11:43:05 -0300
> > > > >>>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> > > > >>>>> On Fri, May 02, 2014 at 03:45:03PM +0200, Igor
Mammedov wrote:
> > > > >>>>>> On Wed, 30 Apr 2014 17:29:28 -0300
> > > > >>>>>> Eduardo Habkost <ehabkost(a)redhat.com>
wrote:
> > > > >>>>>>> This series allows management code to
use object-add on X86CPU subclasses, so it
> > > > >>>>>> Is there any reason why
"device-add" couldn't be used?
> > > > >>>>> It needs to work with "-machine none",
device_add requires a bus to
> > > > >>>>> exist, and there is no icc-bus on machine_none.
> > > > >>>> The thing is that CPUID is a function of machine so
using
> > > > >>>> "-machine none" will provide only
approximately accurate data.
> > > > >>>> I'm not sure that retrieved possibly not
accurate data are useful
> > > > >>>> for libvirt.
> > > > >>> "-cpu host" doesn't depend on machine, and
is the most important thing
> > > > >>> right now (because libvirt's checks for host
QEMU/kernel/CPU
> > > > >>> capabilities is completely broken).
> > > > >> true, but device-add/-cpu host could be used right now to
get the
> > > > >> same CPUID data wile using any machine type or default one
without
> > > > >> any of this patches.
> > > > >
> > > > > device_add can't be used with "-machine none".
> > > >
> > > > I see no reason why we couldn't *make* CPUs work on -machine
none. The
> > > > ICC bus and bridge were a hack to make APIC(?) hot-add work in face
of
> > > > SysBus; if that prohibits other valid uses now, then evaluating
Igor's
> > > > memory work for CPU might be an option.
> > > Yep, if CPU is hot-plugged as bus-less device.
> > > There is a little concern of APIC device if we go that direction since
> > > in addition to hotpluggable BUS, BUS provides address-space for APIC
MMIO.
> > > With that resolved, x86-cpu shouldn't depend on any bus and if there
isn't
> > > any current user that uses QOM path to CPU for introspecting
(Eduardo's
> > > ABI concern), then it could be done in time for 2.1.
> >
> > Maybe there are no users of the current QOM path, but we do need a
> > stable path to allow management to locate the CPU objects. Do we have
> > one, already?
> >
>
> Can't we add query-cpus QMP command or something like this to hide path
> from user.
That would work, too. But why is a dedicated "query-cpus" command better
than something like "qom-list path=/machine/cpus" (that could simply
return a list of links to the actual CPU objects)?
So that not to stall the work on
deciding on
- if exposing not yet stables QOM paths as stable ABI is a good thing, I
recall Andreas objecting to using QOM paths with device hotplug
- what paths to CPUs should be wrt stalled topology discussion
--
Eduardo
--
Regards,
Igor