qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC][PATCH 14/16] kvm: x86: Add user space part for in


From: Jan Kiszka
Subject: Re: [Qemu-devel] [RFC][PATCH 14/16] kvm: x86: Add user space part for in-kernel i8259
Date: Mon, 05 Dec 2011 13:47:34 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2011-12-05 13:36, Avi Kivity wrote:
> On 12/05/2011 01:37 PM, Jan Kiszka wrote:
>> On 2011-12-05 11:01, Avi Kivity wrote:
>>> On 12/04/2011 11:38 PM, Jan Kiszka wrote:
>>>>>
>>>>> It should be also possible to migrate from non-KVM device to KVM
>>>>> version, different names would prevent that for ever.
>>>>
>>>> It is (theoretically) possible with these patches as the vmstate names
>>>> are the same. KVM to TCG migration does not work right now, so I was
>>>> only able to test in-kernel <-> user space irqchip model migrations.
>>>
>>> btw, for the next-gen migration protocol, we'd probably be using QOM
>>> paths, not vmstate names; the QOM paths would include the device name?
>>
>> That would be a very bad idea IMHO. Every refactoring of your device
>> tree, e.g. to model CPU hotplug and the ICC bus more accurately, would
>> risk to create a migration crack.
> 
> At some point, something has to be stable.  We can't have an infinite
> number of layers giving names to things.  I propose we have just one layer.
> 
>>  At least we would need some stable
>> naming and/or alias concept then.
> 
> We should be able to transform a path to backward compatible names,
> yes.  But if something has an unstable name, let's omit it in the first
> place.
> 
> (the memory API added unstable names, hopefully the QOM can take over
> the stable ones and we'll have a good way to denote the unstable ones).
> 

OK, maybe - or likely - we should make those device models have the same
names in QOM once instantiated. But I'm still convinced they should
remain separated models in contrast to a single model with a property.

The kvm ioapic, e.g., requires an additional property (gsi_base) that is
meaningless for user space devices. And its interrupts have to be
wired&configured differently at board model level. So, from the QEMU
POV, it is a very different device. Just the guest does not notice.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]