[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class |
Date: |
Thu, 4 Oct 2012 14:51:13 -0300 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Thu, Oct 04, 2012 at 12:42:23PM -0500, Anthony Liguori wrote:
> 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??
See patch 15/18.
--
Eduardo
- Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class, (continued)
Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class, Anthony Liguori, 2012/10/04
- Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class, Paolo Bonzini, 2012/10/04
- Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class, Andreas Färber, 2012/10/04
- Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class, Anthony Liguori, 2012/10/04
- Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class, Eduardo Habkost, 2012/10/04
- Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class, Anthony Liguori, 2012/10/04
- Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class, Eduardo Habkost, 2012/10/04
- Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class, Anthony Liguori, 2012/10/04
- Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class,
Eduardo Habkost <=
Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class, Eduardo Habkost, 2012/10/04
Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class, Anthony Liguori, 2012/10/04
Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class, Eduardo Habkost, 2012/10/04
Re: [Qemu-devel] [RFC 01/18] pc: create "PC" device class, Anthony Liguori, 2012/10/04
[Qemu-devel] [RFC 04/18] move I/O-related definitions from qemu-common.h to a new header (qemu-stdio.h), Eduardo Habkost, 2012/10/03
[Qemu-devel] [RFC 06/18] hw/apic.c: rename bit functions to not conflict with bitops.h (v2), Eduardo Habkost, 2012/10/03
[Qemu-devel] [RFC 05/18] cpus.h: include qemu-stdio.h, Eduardo Habkost, 2012/10/03