Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Sun, Feb 13, 2011 at 01:38:12PM -0600, Anthony Liguori wrote:
> On 02/13/2011 12:08 PM, Gleb Natapov wrote:
> >On Sun, Feb 13, 2011 at 10:56:30AM -0600, Anthony Liguori wrote:
> >>>>qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device
> >>>>ioapic,id=ioapic,chipset=sb -device
> >>>>cpu,ioapic=ioapic,northbridge=nb
> >>>>
> >>>>Is not all that unreasonable and presents a fully functioning PC.
> >>>Sure.  And -M blah is a shortcut.
> >>Exactly.  Or better yet, blah is a config file that contains
> >>
> >>[device "nb"]
> >>driver=i440fx
> >>
> >You are trying to model how particular (very ancient) HW looked like,
> >instead of emulating guest visible functionality, but is dead end since
> >things are changing constantly. Northbridge functionality moves onto
> >cpu for instance. What CPU i440fx was designed for? Pentium?  What if
> >user runs QEMU with emulated CPU that in real life has internal memory
> >controller? Does you config have sense for such setup? Should we allow
> >to specify only Pentium CPU since this is how real HW worked?
> 
> Yes, how we structure the device tree will change over time.  If
> users have to specify this stuff, we've already failed to start
> with.
> 
And nevertheless this is what you propose here.  User should be able to
specify what devices he wants in a stable format (FDT for instance) and
qemu should create the machine from it. How it is done internally is
different question, but if FDT cannot be reproduced from internal state
we are doing something wrong. The important thing is: we should model how
different parts of HW work together, not how chips are interconnected.
Look at FDTs of real machines. They may contain a lot of devices, but in
reality most of them are sitting in the same chip as CPU.

> The i440fx is definitely guest visible.  And yes, a guest could look
> at freak out that an i440fx is in use with a non-Pentium class CPU.
> We cheat here, and it works just fine.
And not modeling PIIX3 exactly as in real life (by dropping IDE or USB
or even adding ACPI from PIIX4) works just fine (we checked it here
too). And yes, a guest could look into details and freak out too. But
guests don't do that (otherwise they would have to support each chipset
in existence). The state that i440fx expose to a guest is of any interest
only to firmware and luckily we have our own firmware to take care of
the details. PIIX3 is not mush more visible to a guest. This is just
marketing name for collection of HW put in one chip. Remove USB and you
get PIIX2, add ACPI and you get PIIX4. Why would you want to govern qemu
design from such insignificant details?

> 
> >>[device "sb"]
> >>driver=piix3
> >And piix3 refers to piix3.cfg which describe devices that present on the
> >chipset.
> 
> I disagree in this case that it's the best thing to do, but in
> general, yeah, we should provide a mechanism to have essentially
> device tree macros such that one high level device represents a
> larger tree of devices.  This would be a good mechanism to support
> the concept of machines.
> 
> But I don't think we should rely on having this tomorrow as doing
> this well is going to be challenging.
> 
That is what we (almost) have now. If going your direction makes it
challenging we shouldn't go there.

> >>chipset=nb
> >>
> >>[device "ioapic"]
> >>driver=ioapic
> >>chipset=sb
> >Here, for instance, IOAPIC is included in a chipset for a long time
> >now. Why user should care that piix3 didn't have it. How this detail
> >changes qemu functionality? If it doesn't why should we expose it?
> 
> Yeah, I'd be inclined to push the ioapic into the chipset here
> except it may be useful to have multiple ioapics at some point down
> the road.
When machine has multiple ioapic I am almost sure all of them are present
on a chipset, not as stand alone chips. Since having multiple IOAPIC
affects also firmware I am not sure it is useful to support different
number of IOAPICs in qemu.

> 
> Yes, we're exposing gory details of the device model.  No, I don't
> have a problem with that.
> 
> >>[device "cpu"]
> >>driver=cpu
> >>ioapic=ioapic
> >Why ioapic here? Doesn't cpu talks to ioapic via northbridge?
> 
> The i440fx is the northbridge.  For the i440fx, the I/O apic is a
> separate chip.
>
But it is connected to i440fx, not CPU like in your theoretical config.
 
Northbridge, southbridge are just names that do not have any architectural
significance. Like other said in this thread on other architectures
there is no such naming at all. No wonder, since on most embedded archs
(that I know of) all functionality was included on the same chip as
CPU. On x86 PCs historically motherboard had three main chips (cpu, ram
+ pic controller, common hw), so they got those names.  Now in Intel
"Sandy Bridge" all of the functions of the northbridge reside on the
chip itself for instance and I am sure there will be Atoms with all HW
on the same chip.

--
                        Gleb.