On Thu, Oct 04, 2012 at 10:10:16AM -0500, Anthony Liguori wrote:
> Eduardo Habkost <ehabk...@redhat.com> writes:
>
> > On Thu, Oct 04, 2012 at 09:28:13AM -0500, Anthony Liguori wrote:
> >> Paolo Bonzini <pbonz...@redhat.com> 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.
--
Eduardo
