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