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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
