On 08/02/2010 11:34 AM, Gleb Natapov wrote:
On Mon, Aug 02, 2010 at 11:24:14AM +0300, Avi Kivity wrote:
On 08/02/2010 11:17 AM, Gleb Natapov wrote:
We don't know what they'll do. API stability means we only change
things to fix bugs.
Is this API documented? Do we guaranty somewhere anywhere that rip during io
point past the instruction? I think it should be documented that cpu
state cannot be accessed during io emulation.
The user code was written before the documentation.
We did it with unmapped pages in the middles of the slot recently.
What guests did we break?
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.
--
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
