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: Sun, 04 Dec 2011 22:38:45 +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-04 22:31, Blue Swirl wrote:
> On Sun, Dec 4, 2011 at 16:35, Avi Kivity <address@hidden> wrote:
>> On 12/04/2011 05:19 PM, Jan Kiszka wrote:
>>>>
>>>> In the sense that kernel-apic is just an accelerated apic.  From the
>>>> guest point of view, there's no difference, and that should be reflected
>>>> in the device model.
>>>
>>> That was my goal as well: The guest should not notice the difference,
>>> but the admin on the host side should still be able to tell both
>>> internally fairly different models apart.
>>
>> This should be some attribute, not the name.
>>
>>> Plus the code should be
>>> clearly split where there are differences and explicitly shared where
>>> there aren't.
>>
>> That's a good goal, yes.
> 
> I'd prefer an unified device built from a single source file if
> possible. This conflicts with the build-once model though.

Right, another reason to not do this.

> 
>>>
>>>>
>>>> If I'm reading an apic register, either from the guest or via a monitor
>>>> debug interface, I shouldn't care whether it's accelerated or not.  The
>>>> guest part already holds, of course.
>>>
>>> Specifically for the debug scenario, I'd prefer the clear
>>> differentiation by name as there can always remain subtle differences in
>>> the implementation of kernel vs. user space. Someone debugging the guest
>>> and/or qemu/kvm should remain aware of this.
>>
>> Aware, yes, but the name change is too drastic.
> 
> 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.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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