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
vcpu_initialise.patch
Description: Binary data
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home