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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
