Re: [Qemu-devel] [PATCH v2 1/8] kvm: Set cpu_single_env only once

[Blue Swirl]

On Sat, Feb 11, 2012 at 14:18, Jan Kiszka <address@hidden> wrote:
> On 2012-02-11 15:11, Blue Swirl wrote:
>> On Sat, Feb 11, 2012 at 14:00, Jan Kiszka <address@hidden> wrote:
>>> On 2012-02-11 14:54, Blue Swirl wrote:
>>>> On Sat, Feb 11, 2012 at 12:43, Jan Kiszka <address@hidden> wrote:
>>>>> On 2012-02-11 12:49, Andreas Färber wrote:
>>>>>> Am 11.02.2012 12:25, schrieb Blue Swirl:
>>>>>>> I think using cpu_single_env is an indication of a problem, like poor
>>>>>>> code, layering violation or poor API (vmport). What is your use case?
>>>>>>
>>>>>> I couldn't spot any in this series. Jan, note that any new use of env or
>>>>>> cpu_single_env will need to be redone when we convert to QOM CPU.
>>>>>
>>>>> cpu_single_env should have nothing to do with QOM.
>>>>>
>>>>> The ABIs of vmport and the KVM VAPI require a reference to the calling
>>>>> VCPU, and that's why you find tons of them in patch 5.
>>>>
>>>> Yes, this seems to be another case of a badly designed ABI. I guess
>>>> there is no way to change that anymore, just like vmport?
>>>
>>> Believe me, I grumbled over it more than once while porting it from
>>> qemu-kvm. The point is that some (Windows) VMs out there are running
>>> already with this option ROM loaded and working this unfortunate ABI.
>>
>> Maybe in time those could be deprecated and a ROM using a sane ABI
>> introduced instead. After some grace time the old ABI could be finally
>> removed.
>
> At some point. But now we have this interface and no other even thought
> out. Given that we want to provide a migration path from qemu-kvm to
> upstream rather sooner than later, I think there is no way around this
> model for a certain, not too short period.

Yes, that is inevitable.

>>
>>>>
>>>> Some of the cpu_single_env accesses in patch 5 could be avoided when
>>>> APIC is moved closer to CPU. VAPIC should be also close to APIC so it
>>>> should be able to access the CPU directly. In some other cases the
>>>> current state could be passed around instead once it is known.
>>>
>>> Some callbacks are I/O-port originated, ie. not associated with the
>>> per-CPU MMIO area or some MSR. So we would have to pass down the causing
>>> CPU to every I/O handler - not sure if that is desired...
>>
>> I meant things like vapic_enable_tpr_reporting(), current CPUState
>> could be passed via vapic_prepare() easily.
>
> Oh, there is in fact dead code in vapic_enable_tpr_reporting. It just
> iterates over all VCPUs, no need to know the current one.

Ok.

> Jan
>