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

[Gleb Natapov <gleb@redhat.com>]

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.

> >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.
Definitely. That is why I propose enabling e_i_g_s only if qemu
acknowledge that it can use it properly.

> 
> >>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.
> 
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.

> >Boot will take much more time
> >without any gain.
> 
> The gain is correctness.
> 
Agree. Worthy goal.

> >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

--
			Gleb.