On 16.11.2010, at 11:47, Avi Kivity wrote: > On 11/15/2010 06:09 PM, Avi Kivity wrote: >> On 11/15/2010 05:49 PM, Avi Kivity wrote: >>> On 11/15/2010 05:41 PM, Avi Kivity wrote: >>>> >>>> I think it's a miscompile. >>>> >>>> out/code16.o: >>>> 1a4: 3e ds >>>> 1a5: 6c insb (%dx),%es:(%edi) >>>> >>>> Note no 66 prefix. >>>> >>> >>> It isn't, that was random crap. All the insb() code is 32-bit. >>> >> >> Rewriting it to use inb / stos works (jecxz ; insb; loop doesn't) so it >> looks like a kernel bug in insb emulation. >> > > Turns out is was a subtle bug in the tpr optimization we do for Windows XP. > The problem happens when we load the vapic option rom from the firmware > config interface. With inb / movb, writing the vapic area happens in guest > context, which the kernel is prepared to handle. With insb, the write > happens from kvm, which is then undone on the next entry, leading to the tpr > being set to a high value.
Shouldn't the vapic area be mapped in on demand? Then we could map it on option rom init time and everyone's happy. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
