On Mon, Aug 02, 2010 at 11:03:26AM +0300, Avi Kivity wrote: > On 08/02/2010 10:58 AM, Gleb Natapov wrote: > >On Mon, Aug 02, 2010 at 08:04:20AM +0300, Avi Kivity wrote: > >> On 08/01/2010 04:27 PM, Gleb Natapov wrote: > >>>When we are going to enable e_i_g_s by default? > >>Optimistically, 2.6.37, so six months. > >> > >>>May be we have enough > >>>time to fix userspace? > >>Sure we do, but will users update? > >> > >>0.12 is mature enough that some users will forget about it and not > >>update it. > >> > >So they will not update kernel too. 0.12/2.6.32 should be mature combo. > >And we can add patch to 0.12/0.13 stable to work on newer kernels. > > 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. And we can preserve old behaviour for old guests by disabling e_i_g_s for them. > > >But > >realistically the problem will occur only if TPR access is done from big > >real mode by Windows XP running on old Intel cpus. What are the chances > >that this will be a problem in practice? > > 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? Boot will take much more time without any gain. And finally does it access TPR while running in big real mode? > > >>>Too ancient userspace already does not run on recent > >>>kvm. Or may be we can make userspace enable e_i_g_s per guest. This way > >>>userspace that knows it is OK can tell kernel so. > >>Let's make it the other way round, enable the optimization for > >>userspace that declares that it does not make use of rip during > >>emulation (kvm-tpr-opt can be changed by queueing a signal and > >>re-entering the guest to complete the operation). > >> > >>Later we can make the optimization unconditional. > >> > >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. > Step 1: only enable the optimization if userspace indicates it can > handle it. > <time passes> > Step 2: drop the backwards compatibility code, always enable the > optimization. > > -- > 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
