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

[Avi Kivity <avi@redhat.com>]

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.

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.

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

If you have a security issue in code that is exposed to the guest, you 
have to fix it.

-- 
error compiling committee.c: too many arguments to function