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.
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.
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.
If all composition is done through a factory interface, it doesn't.
But my main argument here is that we shouldn't try to make all
composition done through a factory interface--only where it makes
sense.
So very concretely, I'm suggesting we do the following to target-i386:
1) make the i440fx device have an embedded ide controller, piix3,
and usb controller that get initialized automatically. The piix3
embeds the PCI-to-ISA bridge along with all of the default ISA
devices (rtc, serial, etc.).
This may be a problem even from security point of view. What if usb code
(ide, serial, parallel) has guest exploitable bug? Currently I can happily
continue running guests if they do not need affected subsystem. If we'll
get it your way I will no longer be able to do so.
qemu -device i440fx,ide=off
So you still need to support arbitrary composition. What's the
difference?
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.
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.
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.
If you really care to do this. But this desire to remove devices is
silly IMHO. Concerns about security are misplaced. If you have to
change the way a guest is invoked in order to eliminate security
problems, then there's something seriously wrong.
No I do not. I do not create guest with unneeded devices from the
beginning.
There is very little that isn't 'unneeded'.
Regards,
Anthony Liguori
--
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
