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.
And we can preserve old
behaviour for old guests by disabling e_i_g_s for them.
But the user will see a crash first and report a bug. That's not the
experience we want users to have.
Windows XP does use big real mode (I think unintentionally, some
segment registers aren't cleared).
How it works now then? If it works because Windows XP doesn't
realize it runs in big real mode so it doesn't actually access past
segment limit why starting emulating it?
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.
Boot will take much more time
without any gain.
The gain is correctness.
And finally does it access TPR while running in big real
mode?
I don't think so.
What do you call "optimization"? e_i_g_s=1? Isn't it the same as I proposed
then?
The optimization is your patch.
I think there is misunderstanding here. My patch does not change
anything in this regards. If io exit to userspace is done from emulator
rip will point to io instruction with or without my patch and it was always
this way.
In that case the whole thing is moot. When we set eigs=1 we'll have to
test Windows XP and hack around it if needed.
--
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
