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

RE: [Xen-devel] Re: [PATCH 1/4] CPU online/offline support in Xen



Keir Fraser <mailto:keir.fraser@xxxxxxxxxxxxx> wrote:
> On 18/9/08 09:13, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>
>>>> Hmm, I think current NMI_MCE_SOFTIRQ can't make sure other guest will
>>>> not be scheduled. Considering there is a schedule softirq already
>>>> pending on the pCPU, other guest may run before the impacted guest. Did
>>>> I missed anything?
>>>
>>> There are races here in any case. What if #MC happens halfway through the
>>> scheduler, just before set_current(new)?
>>
>> If MCE handler will not cause schedule and not change current, will any
>> issue happen?
>
> I'm not sure exactly what you mean. What *I* meant was that there are
> certain points during execution where, if a #MC occurs, it may not be
> possible to determine which single vCPU was running on the

Current implementation on k8_machine_check, it determine xen_impacted through 
if current is idel domain. And it determine which domain is impacted through 
current. I have no idea of AMD's machine check mechanism, but when considering 
support on intel platform, it may be a bit different. For example, xen is 
impacted if MCE caused by sync event happens in Xen's context, even is not in 
idel domain. Also impacted domain may not always determined by current, memory 
ownership may help to decide impacted domain.

Another difference we are considering is, we suppose domU's MCA handler is not 
trusted, so firstly, we may always need dom0's MCE handler support, secondly, 
after domU MCE handler, some guard may be needed to make sure no error 
triggered again.

> pCPU. I guess
> though that if you ever get unrecoverable errors reported while running
> inside the hypervisor, you probably can't recover anyway.

I think this may depends on the error type. If the error is an async event, it 
may be ok to continue after some containment. For example, if EIPV=0, RIPV=1, 
and ADDRV =1 and happens to xen's execution context, it may because of some 
async event to the memory side, in that situtaion, we can kill the owner of the 
page (if that page is owned exclusively by one guest) and continue run. 
However, if it is a sync event like EIPV=1, then we have to reset the system.

>
> -- 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®.