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

RE: [Xen-devel] RE: [PATCH] Don't enable irq for machine check vmexit



Yes, agree and this patch is ok for me. Thanks very much.

--jyh

>-----Original Message-----
>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>Sent: Friday, February 05, 2010 10:59 PM
>To: Jiang, Yunhong; Tim Deegan
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [Xen-devel] RE: [PATCH] Don't enable irq for machine check vmexit
>
>On 05/02/2010 14:36, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>
>>> How about the attached alternative, which avoids repeated reads of
>>> VM_INTR_INFO? Also I'm not sure whether checking for
>>> VM_EXIT_REASONS_FAILED_VMENTRY is useful, so I removed it. After all,
>>> EXIT_REASON_MCE_DURING_VMENTRY should imply it anyway.
>>
>> Thanks for your patch. Yes, it is much better to avoid the repeated read.
>>
>> I'm not sure if it is ok if we don't check the 
>> VM_EXIT_REASONS_FAILED_VMENTRY.
>> Checking the SDM and seems it is ok. In fact, I didn't find effective method
>> to test this VMEntry MCE failed case, althgouh I can test MCE VMExit with
>> EXIT_REASON_EXCEPTION_NMI case easily. (I will try to find a method to test
>> this VMEntry failure case next week, maybe poison the VMCS range can trigger
>> it, I'm not sure).
>
>Well, we don't seem to know what bit 31 is for. Or, at least, we don't know
>how it should affect our behaviour in the vmexit handler. So looking at it
>does seem a bit pointless.
>
> -- Keir
>


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


 


Rackspace

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