Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class

[Anthony Liguori]

Eduardo Habkost <address@hidden> writes:

> On Thu, Oct 04, 2012 at 10:10:16AM -0500, Anthony Liguori wrote:
>> Eduardo Habkost <address@hidden> writes:
>> 
>> > On Thu, Oct 04, 2012 at 09:28:13AM -0500, Anthony Liguori wrote:
>> >> Paolo Bonzini <address@hidden> writes:
>> >> 
>> >> > Il 04/10/2012 15:46, Anthony Liguori ha scritto:
>> >> >>> > +typedef struct PC {
>> >> >>> > +    DeviceState parent_obj;
>> >> >>> > +} PC;
>> >> >> So the general problem with this approach is that it strays from
>> >> >> modeling hardware.
>> >> >
>> >> > It doesn't really; it's a motherboard object, there's no reason why
>> >> > /machine shouldn't be a Device itself, with a few objects (CPUs, the
>> >> > i440FX, the IOAPIC, and of course the peripherals) hanging off it.
>> >> 
>> >> Okay, but modeling a motherboard is different than creating a "PC"
>> >> object and throwing in the kitchen skink.
>> >> 
>> >> And I'm not sure that going top-down is the best strategy.  I think
>> >> going bottom up makes more sense (starting with modeling Super IO chip).
>> >> 
>> >
>> > So, would you be OK with this implementation if the class were named
>> > "Motherboard", "set-of-CPU-sockets", or something like that?
>> 
>> I would, but you're mixing up modeling with bug fixing.
>> 
>> There's a very easy way to achieve your goal without dramatic
>> remodeling.
>> 
>> Just assign APIC ids during CPU creation and make contiguous_apic_ids a
>> parameter of pc_init1.
>> 
>> You don't need to worry about CPU hotplug.  It doesn't exist in qemu.git
>> and is broken in qemu-kvm.git.
>
> With or without CPU hotplug, the max_cpus variable already exists, and I
> want to avoid breaking code that's already using it, and adding Yet
> Another problem to be fixed by whoever is going to make CPU hotplug
> work.

Sorry, what does max_cpus have to do with apic ids??

Regards,

Anthony Liguori

>
> -- 
> Eduardo