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

[Anthony Liguori]

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.

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

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.

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

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

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

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

Regards,

Anthony Liguori

> --
>                         Gleb.
>