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

RE: [Xen-ia64-devel] [PATCH] Fix freeing of privregs structure fordomVTi


  • To: "Masaki Kanno" <kanno.masaki@xxxxxxxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
  • Date: Fri, 12 Jan 2007 11:01:33 +0800
  • Delivery-date: Thu, 11 Jan 2007 19:01:19 -0800
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: Acc1Wixhid0lNHPyTL2UNqHc7uCYVAAmZs+w
  • Thread-topic: [Xen-ia64-devel] [PATCH] Fix freeing of privregs structure fordomVTi

Masaki Kanno write on 2007年1月11日 16:24:
> Hi,

Hi Kanno,

Good catch!

I have below comment.

The root cause is,  vhpt and privregs for xeno are allocated at hypercall
XEN-DOMCTL_max_vcpus, at that time d->arch.is_vti is not set yet.
When d->arch.is_vti is set, vhpt and privregs allocated for xeno are released, 
and vhpt and privregs for VTI are allocated at this time.

This logic is a little bit ugly.

Can we postpone vhpt and privregs allocation until d->arch.is_vti is set?

One place is at xen/arch/ia64/xen/arch_set_info_guest,

If(d->arch.is_vti)
        vmx_final_setup_guest(v);
Else{ 
/*TODO  We can move vhpt and privregs logic for xeno here. */

}

What's your opinioin?

Thanks,
Anthony

> 
> When I repeated creation and destruction of domVTi, I found a bug.
> It is memory leak of privregs structure.
> This patch fixes the bug.
> 
> Signed-off-by: Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>
> 
> Best regards,
>  Kan

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