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

["Cui, Dexuan" <dexuan.cui@xxxxxxxxx>]

Btw, there are lots of deadly checks such as "BUG()" in vmx.c. Can we change 
them -- only crash the current guest domain? I think this may be better.

 -- Dexuan

>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Cui, Dexuan
>Sent: 2007年3月27日 17:46
>To: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: [Xen-devel] [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 
>>error
>>(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 issue.
>>
>> -- Dexuan
>>
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel