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?
--
Eduardo