[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [Patch] Fix a decode bug in x86_emulate()

  • To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
  • Date: Tue, 27 Mar 2007 17:45:51 +0800
  • Delivery-date: Tue, 27 Mar 2007 02:45:14 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcbhNpSgnLlsyleeR3aZurd/xO5mYAAmjw1QAHpYsZANUy+bAAbmp7kgDVsWwlABkQoy4A==
  • Thread-topic: [Patch] Fix a decode bug in x86_emulate()

When decoding some instructions, such as “ff f3 (push %ebx)”, x86_emulate() 
doesn’t check the type of operand. The attached patch fixes the issue.

Signed-off-by: Dexuan Cui <dexuan.cui@xxxxxxxxx>

>-----Original Message-----
>From: Cui, Dexuan
>Sent: 2007年3月19日 18:57
>To: '
>Cc: 'Keir Fraser'
>Subject: [Patch] lower the frequency of HPET device model to 1/32 of TSC's
>The frequency of HPET device model is defined to be the same as TSC's, but 
>unluckily this
>doesn't work well with calibrate_tsc_hpet() in Linux kernel 2.6.16-33, causing 
>some IA32
>Linux HVM guests can't boot sometimes.
>Calibrate_tsc_hpet() tries figuring out how many HPET ticks a TSC cycle 
>equals; it
>magnifies the result by scale of 2^32, trying to get a more accurate result 
>since it
>assumes the frequency of HPET in real world is usually less than 1/100 of TSC, 
>so the
>result of "(2^32 * hpet_freq) / tsc_freq" may exceed 32bits, then a "divide 
>(overflow)" would occur!
>The result doesn't overflow every time because hpet_freq/tsc_freq may less 
>than 1.0 due
>to the little inaccuracy in the implementation of HVM timer virtualization.
>The patch lowers the frequency of HPET device mode to 1/32 of TSC's to fix the 
> -- Dexuan

Attachment: x86_emulate.c.diff
Description: x86_emulate.c.diff

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.