[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
Description: Binary data

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