[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |