On Thu, Apr 08, 2010 at 09:54:35AM +0200, Jan Kiszka wrote: > >>>> The following patch fixes it, but it has some drawbacks: > >>>> > >>>> - cpu_synchronize_state+writeback is noticeably slow with tpr patching, > >>>> this makes it slower. > >>>> > >>>> > >>> Isn't it a very rare event? > >>> > >> It has to be - otherwise the decision to go for full sync and individual > >> get/set IOCTL would have been wrong. What happens during tpr patching? > >> > >> > > > > tpr patching listens for instructions which access the tpr and patches > > them to a call instruction (targeting some hacky code in the bios). > > Since there are a limited number of such instructions (20-30 IIRC) you > > expect tpr patching to happen very rarely. > > Then I wonder why it is noticeable. While switching kvm-tpr-opt.c from explicit {get,put}_{s}regs to cpu_synchronize_state+writeback i noticed WinXP.32 boot became visually slower. For some reason, the delay introduced by cpu_synchronize_state+writeback forbids patching certain instructions for longer periods, or somehow allows Windows to use unpatched instructions more often </guess>. End result was 4x more patching (from 700 to 4000, roughly). Confirmed it was a timing issue by introducing delays to original {get,put}_{s}regs version. The particular tpr case is no big deal since as mentioned its a short lived period, but for things like Kemari this might be an issue. But this is another discussion. -- 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