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

[Gleb Natapov]

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). AFAIC
there are PCs without RTC already. 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"?

> >>>>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.
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.

> 
> >  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?

> 
> >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.

> 
> >>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'.
> 
That depends on the guest. For guest that needs only disk and network
much can be omitted.

--
                        Gleb.