Re: [PATCH 1/2] KVM: x86 emulator: don't update vcpu state if instruction is restarted.

[Avi Kivity <avi@redhat.com>]

  On 08/02/2010 12:05 PM, Gleb Natapov wrote:
>>>
>>> We did it with unmapped pages in the middles of the slot recently.
>> What guests did we break?
>>
> The one that uses device assignment with old qemu-kvm userspace. Old
> qemu-kvm copied assigned card's ROM into memory and made it read
> only (mprotect(RO)) to get MMIO exists on it. Even older device
> assignment code unmapped one page in the middle of a slot to get mmio
> exist if the page is accessed (and this breaks if mmap decides to mmap
> something else there).

That's fine, device assignment is specialized enough.  I'm more worried 
about everyday workloads.

>>>> IIRC it leaves fs and gs pointing to large segments, but it never
>>>> accesses them.  Since we can't tell whether the guest will use those
>>>> segments, we can't avoid emulating big real mode.  Right now most
>>>> things work, but that's because we hacked around everything.
>>>>
>>> We have logic in TPR patching code that tries to detect WindowsXP guest
>>> and if XP is detected it enables vapic. We can disable e_i_g_s if vapic
>>> is enabled.
>> That code is in userspace.  If we can change userspace, the whole
>> problem is gone.
> Userspace calls kvm_enable_vapic() to let kernel know that vapic is
> enabled.

This happens before the vapic is detected.

In fact, this particular port is during option rom initialization; I 
don't think it's in big real mode.

-- 
error compiling committee.c: too many arguments to function