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

RE: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed



Hi Anthony,

I think that vmx_final_setup_guest() is called asynchronously.
Because the secondary vcpus are waken by IPI, not control panel.
Actually we can observe the following log message asynchronously.
(XEN) arch_boot_vcpu: vcpu 1 awaken 00000000046bc180!

vmx_relinquish_vcpu_resources() is called after sched_destroy_domain().
If the scheduler stops vcpus completely in sched_destroy_domain(),
it might be OK. But it seems to be up to scheduler.

Thanks,
Kouya

Xu, Anthony writes:
 > >From: Kouya SHIMURA [mailto:kouya@xxxxxxxxxxxxxx]
 > >Sent: 2006年10月11日 12:41
 > >To: Xu, Anthony
 > >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
 > >Subject: RE: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed
 > >Hi Anthony,
 > >
 > >Thanks for your comment.
 > >If it is safe that vmx_reliquish_vcpu_resouces(vcpu) is called
 > >before the vcpu is booted, your modification looks better.
 > >
 > >I'm afraid of the race condition between vmx_final_setup_guest()
 > >and vmx_relinquish_vcpu_resources().
 > >Supposing such a condition, we might have to use some lock in order to
 > >prevent memory leak. How do you think?
 > 
 > I see your point,
 > In this situation, vmx_final_setup_guest() and 
 > vmx_relinquish_vcpu_resources()
 > are called by control panel, they should not be called serially not 
 > simultaneously.
 > 
 > 
 > Anthony


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


 


Rackspace

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