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.
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.
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
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.
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.
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.
OTOH, skipping any notion of machine and explicitly creating a chipset
provides a very consistent architecture.
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.
Regards,
Anthony Liguori
--
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
