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

Anthony Liguori
2011-02-10T10:19:53Z

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