On Thu, Feb 10, 2011 at 01:47:06PM +0100, Anthony Liguori wrote: > On 02/10/2011 11:49 AM, Gleb Natapov wrote: > >On Thu, Feb 10, 2011 at 11:19:48AM +0100, Anthony Liguori wrote: > >>On 02/10/2011 11:10 AM, Gleb Natapov wrote: > >>>On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote: > >>>>On 02/10/2011 10:07 AM, Gleb Natapov wrote: > >>>>>So what if it is easier, it doesn't mean it is correct thing to do. > >>>>If we spend the next 10 years trying to do the "correct thing" for > >>>>some arbitrary definition of correct, that's not terribly useful. > >>>Changing direction by 180 every 2 years even less useful. > >>If we think through what we are doing and have a coherent > >>architecture before changing direction, then we won't have this > >>problem. > >> > >I'd like to believe this :) > > > >>>>It's really simple actually. Let's do the least clever thing and > >>>>model how hardware actual works. Once we have that, we can try to > >>>>be better than real hardware (if it's possible). > >>>I think out understanding on how HW actually works is very different. > >>>You are placing to much value on were device resides physically, for me > >>>it is completely unimportant detail. Not worth even mentioning. > >>No, I place value on how things are modelled in the real world. > >Real world (physical HW) have consideration not relevant for our > >software emulation. Such as cost, physical dimension, power consumption > >and many other I am sure I missed. > > > >>There simply aren't PC's out there that lack an RTC so I have no > >>interest in jumping through hoops in QEMU to make it possible to do > >>this without modifying QEMU code. It might sound nice to a > >>developer but it's of absolutely no use to users. > >> > >RTC is not good example. HPET suppose to replace it (and PIT too). > > HPET's embed RTCs to provide support for legacy implementations. > This is extremely good example of where our modelling breaks down. > Take a close look at how the HPET and RTC emulations interact for an > example of why we'd be much better off just implementing an RTC > within an HPET. > Yes HPET can provide legacy RTC timer functionality. No I do not see why we should implement RTC withing HPET. In your model we should remove HPET code completely since HPET is not present in chipset emulated by QEMU. > > AFAIC > >there are PCs without RTC already. > > RTC also provides CMOS functionality and no PC can boot without > CMOS. So no, there's nothing we'd consider a PC today that doesn't > have an RTC. CMOS may be present even if RTC functionality is absent. Does EFI base machine still need CMOS though? > > > Good example would be PIC or IOAPIC > >device and then I would agree with you that it is not worth it to make > >it possible to create x86 machine without them from command line if it > >means extra complexity. But how have you jumped from this to "lets make usb > >mandatory"? > > USB is mandatory in the PIIX3 but the only significant difference > between the piix2 and piix3 is the addition of USB. > Consequentially, the main difference between an i440fx and i440bx is > the use of a piix2 vs. a piix3. So if you really want to create the > same PC we have today w/o USB, the right way to do it would be to > have: > > -device i440,model=fx // with USB > -device i440,model=bx // w/o USB Why not qemu -config piix2.cfg or qemu -config piix3.cfg? No need to make data into code. > > > >>No, we don't. It's possible to have an 'rtc=off' option but I'm > >>tremendously opposed to doing this. Arbitrary composition is not a > >>useful goal IMHO. > >IMHO is different. We should support composition where it makes sense. > >For PIC-less x86 it doesn't make it. For usb-less or even ide-less it > >does. > > The right way to do a USB-less PC is to have an option to create an i440bx. Why is this the right way? > > An IDE-less PC is a bit more difficult because IDE is really baked > into the concept of a PC. Chances are, there are more than a few > guests out there that would have issues from there being no IDE bus > present. > Non of my modern PCs have IDE. Many high end PC had SCSI instead of IDE in the past. If guest can't run without IDE you do not run it without IDE. > >>> So why do you like -device i440fx over what we have now? > >>Because I don't think tools like libvirt should be doing device > >>composition to create an i440fx-like chipset. I think the current > >>path we're on is pushing too much logic that belongs in QEMU into > >>the management stack. > >I can agree with that. But from this it doesn't follow that we should > >get rid of composition. We shouldn't push composition of common HW to > >libvirt. Looking at libvirt command line I do not think we do it though. > >Typical libvirt command line specifies disks, networks, usb, vga. How > >-device i440fx will simplified that? Well usb could be omitted (but not > >-usbdevice table), disks are not property of i440fx so they will stay, > >since user may want to use virtio controller (which is not part of > >i440fx) this should stay too. Network obviously will have to be > >specified by libvirt too, vga may go to i440fx, but since libvirt > >supports qxl we will have to have a way to disable default vga and > >enable qxl instead. So will we really simplify libvirt's life by > >introducing -device i440fx? > > libvirt also uses -no-defaults which prevents much of the PC's > machine init from creating anything but stuff that really belongs in > the main chipset. > > But I bet if you asked 5 different QEMU developers what belongs in > machine init and what the role of -no-defaults is, you'd get > different answers. > IIRC -no-defaults was created because the flexibility of creating different HW configuration was needed, not just because someone had to much time on its hands. Removing flexibility does not solve original problem. > OTOH, skipping any notion of machine and explicitly creating a > chipset provides a very consistent architecture. Just hard code everything and supporting only one HW configuration provides even better consistency. Is this the right thing to do? > > >>>In current speak you propose will be implement by using i440fx machine > >>>type. Qdev will build it for you. > >>If you had an i440fx machine type, that had no non-optional > >>components added, and you could specify options to the machine type, > >>yes. But I think you'll agree that there's no reason to not just > >>treat the i440fx as a device. > >I do not agree. There is not such device as i440fx. This is just > >packaging. > > Nope, that's definitely not true. There's quite a bit of logic that > is in the silicon that is not part of PIIX3. > What logic exactly? Where this logic described? -- 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
