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

[Gleb Natapov]

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<address@hidden>  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.

> Basically, we're making things much harder for ourselves than we should.
> 
> >>We want to have an interface to create large chunks of hardware (like an
> >>i440fx) which then results in a significant portion of a device tree.
> >But how would this affect interface to devices? I don't see how that
> >would be any different with current model and the function call model.
> 
> 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.

> 
> 2) get rid of the entire concept of machines.  Creating a i440fx is
> essentially equivalent to creating a bare machine.
> 
> 3) just use the existing -device infrastructure to support all of
> this.  A very simple device config corresponds to a very complex
> device tree but that's the desired effect.
> 
> 4) model the CPUs as devices that take a pointer to a host
> controller, for x86, the normal case would be giving it a pointer to
> i440fx.
> 
> Regards,
> 
> Anthony Liguori
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to address@hidden
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
                        Gleb.