Xen devel - Aug 2006 - [Xen-ia64-devel] Porting PV-on-HVM for ia64 platform

Hi all,

My name is Tsunehisa Doi.

We have been porting PV-on-HVM feature for ia64 platform.

I will post patches for PV-on-HVM on ia64 platform. These patches modify
common code for PV-on-HVM on IPF.

We ported PV-on-HVM for IPF under this consideration:

* Expand hvm_op hypercall
+ Introduce HVMOP_setup_shared_info_page
- A page allocated on HVM-guest OS is swapped original shared_info
page with this hypercall.
- In x86 code, original shared_info page is used after pv-on-hvm
setup with remapping feature in arch depend HYPERVISOR_memory_op.
But, we can''t implement same feature for IPF, thus we select to
implement with this method.
+ Introduce HVMOP_setup_gnttab_table
- Pages allocated on HVM-guest OS is swapped original grant_table
page frames with this hypercall.
- Same above.
* Change domain destroy logic
+ arch_domain_destroy() changed
- considered for swapping shared_info page.
+ grant_table_destroy() changed
- considered for swapping grant_frame pages.
* Modify linux-sparse for pv-on-hvm
+ gnttab.c in linux-sparse modified at initialization
+ modify hypervisor.h for pv-on-hvm
* Modify unmodified_drivers initialization
+ considered the different initialization with x86 code. + modify build
rule for IPF

This patch includes:

* destroy-common.patch
- grant_table destroy logic modification for PV-on-HVM on IPF
* linux-common.patch
- linux-sparse modification for PV-on-HVM on IPF
* unmodified-common.patch
- unmodified_drivers modification for IPF
* unmodified-build.patch
- unmodified_drivers build rule modification for IPF

We have tested that this patch doesn''t affect dom0, domVTi without
pv-on-hvm driver attaching, and domVTi using pv-on-hvm driver works
VBD/VNIF on IPF.

Thanks,
- Tsunehisa Doi







_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Tsunehisa Doi wrote:
> Hi all,
> My name is Tsunehisa Doi.
> We have been porting PV-on-HVM feature for ia64 platform.
>   
Sorry, This message is difficult to read. I''ll resend same.

Hi all,

My name is Tsunehisa Doi.

We have been porting PV-on-HVM feature for ia64 platform.

I will post patches for PV-on-HVM on ia64 platform. These patches modify
common code for PV-on-HVM on IPF.

We ported PV-on-HVM for IPF under this consideration:

* Expand hvm_op hypercall
+ Introduce HVMOP_setup_shared_info_page
- A page allocated on HVM-guest OS is swapped original shared_info
page with this hypercall.
- In x86 code, original shared_info page is used after pv-on-hvm
setup with remapping feature in arch depend HYPERVISOR_memory_op.
But, we can''t implement same feature for IPF, thus we select to
implement with this method.
+ Introduce HVMOP_setup_gnttab_table
- Pages allocated on HVM-guest OS is swapped original grant_table
page frames with this hypercall.
- Same above.
* Change domain destroy logic
+ arch_domain_destroy() changed
- considered for swapping shared_info page.
+ grant_table_destroy() changed
- considered for swapping grant_frame pages.
* Modify linux-sparse for pv-on-hvm
+ gnttab.c in linux-sparse modified at initialization
+ modify hypervisor.h for pv-on-hvm
* Modify unmodified_drivers initialization
+ considered the different initialization with x86 code.
+ modify build rule for IPF

This patch includes:

* destroy-common.patch
- grant_table destroy logic modification for PV-on-HVM on IPF
* linux-common.patch
- linux-sparse modification for PV-on-HVM on IPF
* unmodified-common.patch
- unmodified_drivers modification for IPF
* unmodified-build.patch
- unmodified_drivers build rule modification for IPF

We have tested that this patch doesn''t affect dom0, domVTi without
pv-on-hvm driver attaching, and domVTi using pv-on-hvm driver works
VBD/VNIF on IPF.

Thanks,
- Tsunehisa Doi





_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Hi all,

  Sorry, I have tried to repost it, but my mail tool reformated with format
which I don''t want.

I (Doi.Tsunehisa) said:
> Tsunehisa Doi wrote:
>> Hi all,
>> My name is Tsunehisa Doi.
>> We have been porting PV-on-HVM feature for ia64 platform.
>>   
> Sorry, This message is difficult to read. I''ll resend same.
Thanks,
- Tsunehisa Doi

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

On 26/8/06 6:50 am, "Tsunehisa Doi"
<Doi.Tsunehisa@jp.fujitsu.com> wrote:
> - In x86 code, original shared_info page is used after pv-on-hvm
> setup with remapping feature in arch depend HYPERVISOR_memory_op.
> But, we can''t implement same feature for IPF, thus we select to
> implement with this method.
Why is that? It''s a change to the P2M map -- it''s not an
x86-specific
operation.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

You (Keir.Fraser) said:
> On 26/8/06 6:50 am, "Tsunehisa Doi"
<Doi.Tsunehisa@jp.fujitsu.com> wrote:
>> - In x86 code, original shared_info page is used after pv-on-hvm
>> setup with remapping feature in arch depend HYPERVISOR_memory_op.
>> But, we can''t implement same feature for IPF, thus we select
to
>> implement with this method.
> 
> Why is that? It''s a change to the P2M map -- it''s not an
x86-specific
> operation.
  We had tried to implement it with the same method as x86 code, but we
couldn''t success to implement it. If we will refere to implementation
of
grant table operation, we may be able to success to implement it, but
it''s not easy for us, I think.

Thanks,
- Tsunehisa Doi

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

I (Doi.Tsunehisa) said:
> You (Keir.Fraser) said:
>> On 26/8/06 6:50 am, "Tsunehisa Doi"
<Doi.Tsunehisa@jp.fujitsu.com> wrote:
>>> - In x86 code, original shared_info page is used after pv-on-hvm
>>> setup with remapping feature in arch depend HYPERVISOR_memory_op.
>>> But, we can''t implement same feature for IPF, thus we
select to
>>> implement with this method.
>> 
>> Why is that? It''s a change to the P2M map -- it''s not
an x86-specific
>> operation.
> 
>   We had tried to implement it with the same method as x86 code, but we
> couldn''t success to implement it. If we will refere to
implementation of
> grant table operation, we may be able to success to implement it, but
> it''s not easy for us, I think.
  I''ll try to describe the reasoon which I think about.

  In IPF, V2P address translation uses TR, TC and VHPT. VHPT is like page
table in x86 platform, and TC is like TLB in it exept for direct handling
posibility. But TR is specific for IPF. TR is controled directly with MM,
its entry does not be deleted by hardware if MM does not control it.

  In additionaly, TR, TC and VHPT can use flexible page size for each entry.
Thus normal linux kernel uses a TR entry for kernel virtual space. So, in HVM
domain on IPF, it is difficult to change a part of P2M map of kernel virtual
space without MM modification.

Thanks,
-- Tsunehisa Doi



_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

On 26/8/06 10:52 pm, "Doi.Tsunehisa@jp.fujitsu.com"
<Doi.Tsunehisa@jp.fujitsu.com> wrote:
>   In IPF, V2P address translation uses TR, TC and VHPT. VHPT is like page
> table in x86 platform, and TC is like TLB in it exept for direct handling
> posibility. But TR is specific for IPF. TR is controled directly with MM,
> its entry does not be deleted by hardware if MM does not control it.
> 
>   In additionaly, TR, TC and VHPT can use flexible page size for each
entry.
> Thus normal linux kernel uses a TR entry for kernel virtual space. So, in
HVM
> domain on IPF, it is difficult to change a part of P2M map of kernel
virtual
> space without MM modification.
What''s a TR? Assuming some sort of virtual->physical translation
record, you
couldn''t have simple single mapping for the entire kernel va space
because
it won''t map onto a contiguous block of physical addresses? There must
be
something doing translation from the guest''s view of fake contiguous
physical memory to underlying real scattered pages -- whatever structure
that is is the one that gets modified by that memory_op.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

You (Keir.Fraser) said:
> On 26/8/06 10:52 pm, "Doi.Tsunehisa@jp.fujitsu.com"
> <Doi.Tsunehisa@jp.fujitsu.com> wrote:
> 
>>   In IPF, V2P address translation uses TR, TC and VHPT. VHPT is like
page
>> table in x86 platform, and TC is like TLB in it exept for direct
handling
>> posibility. But TR is specific for IPF. TR is controled directly with
MM,
>> its entry does not be deleted by hardware if MM does not control it.
>> 
>>   In additionaly, TR, TC and VHPT can use flexible page size for each
entry.
>> Thus normal linux kernel uses a TR entry for kernel virtual space. So,
in HVM
>> domain on IPF, it is difficult to change a part of P2M map of kernel
virtual
>> space without MM modification.
> 
> What''s a TR? Assuming some sort of virtual->physical
translation record, you
> couldn''t have simple single mapping for the entire kernel va space
because
> it won''t map onto a contiguous block of physical addresses? There
must be
> something doing translation from the guest''s view of fake
contiguous
> physical memory to underlying real scattered pages -- whatever structure
> that is is the one that gets modified by that memory_op.
  Sorry, I had misunderstood the TR/TC emulation for VT-i domain.

  I thought that one virtual TR/TC entry was emulated with one physical
TC entry, and whole kernel virtual space used only one physical TC entry.
Thus, a part of pages in kenrnel virtual space could not remapping to
the other memory page, I thought.

  Today, I discussed with my co-worker about this feature. So, one
virtual TR/TC is emulated with some physical VHPT entry per Xen pagesize.
Thus, we should be able to implement with same method of x86 code.

  Currently, we are trying to modify PV-on-HVM feature for IPF with
the same method of x86 code. And in preliminary implement, we could do
the feature.

Thanks,
- Tsunehisa Doi

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Hi,

Doi.Tsunehisa@jp.fujitsu.com wrote:
>   Currently, we are trying to modify PV-on-HVM feature for IPF with
> the same method of x86 code. And in preliminary implement, we could do
> the feature.
  I will post patches for PV-on-HVM on ia64 platform. These patches
modify common code for PV-on-HVM on IPF.

  We ported PV-on-HVM for IPF under this consideration:

   * Expand memory_op hypercall
     + Introduce XENMEM_add_to_physmap
       - A virtual space allocated on HVM-guest OS is remapped original
         shared_info and grant_table page with this hypercall.
       - This method is same as x86 method.
   * Reduce hvm_op hypercall
     + Delete functions introduced for old PV-on-HVM on IPF.
   * Revert domain destroy logic
     + revert arch_domain_destroy() for old PV-on-HVM on IPF.
   * Modify unmodified_drivers initialization
     + cut off unused codes for IPF
     + modify build rule for IPF

  These patch include: (common code)

   * unmodified-driver.patch
     - unmodified_drivers modification for IPF
   * unmodified-build.patch
     - unmodified_drivers build rule modification for IPF

  We have tested that this patch doesn''t affect dom0, domVTi without
pv-on-hvm driver attaching, and domVTi using pv-on-hvm driver works
VBD/VNIF on IPF.

Thanks,
- Tsunehisa Doi



_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel