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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

On 2011-12-04 22:31, Blue Swirl wrote:
> On Sun, Dec 4, 2011 at 16:35, Avi Kivity <avi@redhat.com> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]