Re: [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing

[Eduardo Habkost]

On Tue, May 06, 2014 at 10:29:24PM +0200, Andreas Färber 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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.
> 
> I'm not aware of any real X86CPU dependency on ICCBus, so we might as
> well make -device place it on SysBus if no ICCBus is available...
> probably much more invasive and potentially dangerous though.

Doing that may be an option, too. But isn't the X86CPU bus type and
object hierarchy part of the API?

Anyway, I thought we were moving away from QDEV, and trying to use a
purely QOM-based model where possible. So I don't see why making
object-add working with X86CPU would be a bad thing, considering that
the alternative requires redoing the X86CPU bus/device hierarchy again,
just to work around device_add limitations.

My other worry is if X86CPU/icc-bus hierarchy rework would be done in
time for 2.1 (and not delay other work). The lack of proper host
capability probing in the libvirt+QEMU stack is a bug, not just a nice
new feature.

-- 
Eduardo