This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Li, Xin B" <xin.b.li@xxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Mallick, Asit K" <asit.k.mallick@xxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Subject: RE: [Xen-devel] credit scheduler issues in 64bit hypervisor
From: "Li, Xin B" <xin.b.li@xxxxxxxxx>
Date: Sun, 2 Jul 2006 12:01:07 +0800
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Steven Hand <Steven.Hand@xxxxxxxxxxxx>, "Zheng, Jeff" <jeff.zheng@xxxxxxxxx>
Delivery-date: Sat, 01 Jul 2006 21:01:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcadKK7o+ueAUe+mRwSgxKbekE+hbgABcMxgABWYtfA=
Thread-topic: [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