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
