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