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

[Gleb Natapov <gleb@redhat.com>]

On Thu, Feb 10, 2011 at 12:25:38PM +0200, Avi Kivity wrote:
> On 02/10/2011 11:07 AM, Gleb Natapov wrote:
> >On Thu, Feb 10, 2011 at 08:47:12AM +0100, Anthony Liguori wrote:
> >>  On 02/09/2011 09:15 PM, Blue Swirl wrote:
> >>  >On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori<anthony@codemonkey.ws>   wrote:
> >>  >>On 02/09/2011 06:48 PM, Blue Swirl wrote:
> >>  >>>>ISASerialState dev;
> >>  >>>>
> >>  >>>>isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);
> >>  >>>>
> >>  >>>Do you mean that there should be a generic way of doing that, like
> >>  >>>sysbus_create_varargs() for qdev, or just add inline functions which
> >>  >>>hide qdev property setup?
> >>  >>>
> >>  >>>I still think that FDT should be used in the future. That would
> >>  >>>require that the properties can be set up mechanically, and I don't
> >>  >>>see how your proposal would help that.
> >>  >>>
> >>  >>Yeah, I don't think that is a good idea anymore.  I think this is part of
> >>  >>why we're having so many problems with qdev.
> >>  >>
> >>  >>While (most?) hardware hierarchies can be represented by device tree syntax,
> >>  >>not all valid device trees correspond to interface and/or useful hardware
> >>  >>hierarchies.
> >>  >User creates a non-working machine and so gets to fix the problems?
> >>  >How is that a problem for us?
> >>
> >>  It's not about creating a non-working machine.  It's about what
> >>  user-level abstraction we need to provide.
> >>
> >>  It's a whole lot easier to implement an i440fx device with a fixed
> >>  set of parameters than it is to make every possible subdevice have a
> >>  proper factory interface along with mechanisms to hook everything
> >>  together.
> >>
> >So what if it is easier, it doesn't mean it is correct thing to do. What
> >you are proposing is just a huge step backwards. May be we shouldn't
> >support hooking everything together in completely arbitrary ways, but we
> >shouldn't force isa/pci devices upon our users just because they are
> >non-removable on real chip.
> 
> I disagree.  We don't want to deviate from the spec any more than we
> already do.
> 
Which spec? Even in this discussion we completely mixed different
things. 440FX is not a chipset. It is memory controller/pci host bridge.
PIIX3/4 is the chipset which is just an arbitrary combination of devices
put on the same chip. We do not deviate from spec when we implement
those devices.

> The reason for wanting flexibility is because the code for the PIC
> or RTC, for example, can be used in other Super-IO chipsets or even
> standalone.  If qemu only supported the 440FX chipset, we'd have no
> reason to make things flexible.
Again you probably mean PIIX3. Even then removing unused ide will free
one more PCI slot for my cool virtio disk array. The things is, from
code point of view, it does not cost you extra to allow composition of
ide since it is just a regular PCI device and we need to support composing
those anyway.

> 
> >>
> >>  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.
> 
> You can't just remove a device from a guest.  You have to shut it
> down.  When you power it back up, you may end up with different IRQ
> assignments or expose some guest bug.
As I answered to Anthony already I am not talking about changing HW
configuration after guest is created rather about creating minimal HW
setup for the task from the start. This means no soundcard or usb for
Windows exchange server for instance.

> 
> If you have a security issue in code that is exposed to the guest,
> you have to fix it.
> 
Of course. That is why it is a good idea to expose as little code to
guest as possible. Don't you think so?

--
			Gleb.