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

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&gt; 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&gt; 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&gt; 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&gt; 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?