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

RE: [Xen-devel] credit scheduler issues in 64bit hypervisor

>>-----Original Message-----
>>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
>>Sent: 2006年7月2日 0:02
>>To: Li, Xin B
>>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Ian Pratt; Rik van Riel; 
>>Steven Hand; Zheng, Jeff
>>Subject: Re: [Xen-devel] credit scheduler issues in 64bit hypervisor
>>On 1 Jul 2006, at 16:22, Li, Xin B wrote:
>>> This is caused by a vmcs bug, the root cause is on x86_64, a 
>>VMX domain
>>> is killed without any vmentry (caused by "Error: Device 768 
>>(vbd) could
>>> not be connected. Hotplug scripts not working."), but then a 
>>> still executed on its unlaunched VMCS.
>>> the following patch fixes it.
>>> Signed-off-by: Xin Li <xin.b.li@xxxxxxxxx>
>>This patch is itself buggy: Just because a VMCS hasn't been launched 
>>doesn't mean it hasn't been activated on some CPU. 

Hmm, thinking about a VMCS is migrating from cpu A to cpu B, and on cpu A 
vmclear has been executed, but just before the VMCS is launched on cpu B, the 
domain is killed, what will happen?
I'm not sure if vmclear on a VMCS in cleared state is allowed. If not, we still 
need this fix.

>>I think the original 
>>bug would be better fixed by only calling vmx_clear_vmcs() in 
>>vmx_destroy_vmcs() if arch_vmx->vmcs != NULL. Even better 
>would be not 
>>to allocate the VMCS so darn late.
>Yes, it's buggy, and prevent the first vmclear to a vmcs.

I found even without my fix the first vmclear to a newly allocated vmcs is 
prevented, this is because arch_vmx->active_cpu = -1is executed  before 
vmx_clear_vmcs(v) in construct_vmcs().
We may workaound it by setting active_cpu to smp_processor_id(), and launched 
to 1here, but surely this is not what we want.


Xen-devel mailing list



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