Sorry, I forgot to attach test results.
- Booting Xen and booting dom0-SMP(16 CPUs) test passed.
- Repeating test of creation and destruction of guest domain
passed, and I was not able to find memory leak in xenheap.
-- domU-UP
-- domU-SMP(16 CPUs)
-- domVTi-UP
-- domVTi-SMP(16 CPUs)
Best regards,
Kan
>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
>
>-------------------------------text/plain-------------------------------
>_______________________________________________
>Xen-ia64-devel mailing list
>Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-ia64-devel
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home