[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-ia64-devel] [PATCH] Fix freeing of privregs structure fordomVTi
Hi, I made a patch to modify initialization of VCPU of dom0/domU. 1) This patch moved some processing from vcpu_initialise() and added a new function vcpu_late_initialise(). It executes the following initializations for VCPU of dom0/domU. - Allocate the VHPT - Allocate the privregs area and assign these pages into guest pseudo physical address space. - Set the tlbflush_timestamp. It is executed in the following sequence. dom0: start_kernel() ->domain_create() ->alloc_vcpu(VCPU0) ->alloc_vcpu_struct(VCPU0) ->vcpu_initialise(VCPU0) ->vcpu_late_initialise(VCPU0) ->construct_dom0 ->alloc_vcpu(othe VCPUs) ->alloc_vcpu_struct(other VCPUs) ->vcpu_initialise(other VCPUs) ia64_hypercall(FW_HYPERCALL_IPI) ->fw_hypercall_ipi(XEN_SAL_BOOT_RENDEZ_VEC) ->arch_set_info_guest(other VCPUs) ->vcpu_late_initialise(other VCPUs) domU: do_domctl(XEN_DOMCTL_createdomain) ->domain_create() do_domctl(XEN_DOMCTL_max_vcpus) ->alloc_vcpu(all VCPUs) ->alloc_vcpu_struct(all VCPUs) ->vcpu_initialise(all VCPUs) do_domctl(XEN_DOMCTL_setvcpucontext) ->set_info_guest(VCPU0) ->arch_set_info_guest(VCPU0) ->vcpu_late_initialise(VCPU0) ia64_hypercall(FW_HYPERCALL_IPI) ->fw_hypercall_ipi(XEN_SAL_BOOT_RENDEZ_VEC) ->arch_set_info_guest(other VCPUs) ->vcpu_late_initialise(other VCPUs) 2) This patch modified the domain_set_shared_info_va(). Currently, initialization of arch.privregs->interrupt_mask_addr of all VCPUs is executed in domain_set_shared_info_va(). However, allocation of privregs area is late by modified of 1). Therefore, this patch modified initialization of arch.privregs->interrupt_mask_addr to the following sequence. dom0 and domU: ia64_hypercall(FW_HYPERCALL_SET_SHARED_INFO_VA) ->domain_set_shared_info_va() Initialize interrupt_mask_addr of VCPU0 ia64_hypercall(FW_HYPERCALL_IPI) ->fw_hypercall_ipi(XEN_SAL_BOOT_RENDEZ_VEC) ->arch_set_info_guest(other VCPUs) ->vcpu_late_initialise(other VCPUs) Initialize interrupt_mask_addr of other VCPUs Signed-off-by: Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx> Best regards, Kan >Hi kanno, > >> >> I'll try it. Could you wait a few days? >> >That's ok. >Thanks for taking this > >Anthony > >Masaki Kanno write on 2007年1月12日 16:18: >> Hi Anthiny, >> >>> 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. >> >> I also think so. >> >>> Can we postpone vhpt and privregs allocation until d->arch.is_vti is >>> set? >> >> I'll try it. Could you wait a few days? >> >> Best regards, >> Kan >> >>> 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 Attachment:
vcpu_initialise.patch _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ia64-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |