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

[Anthony Liguori <anthony@codemonkey.ws>]

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