relationship of the auto_translated_physmap feature and the shadow_mode_translate mode of domain

relationship of the auto_translated_physmap feature and the shadow_mode_translate mode of domain

[HuYanyan]

[-- Attachment #1.1: Type: text/plain, Size: 2179 bytes --]

Hi All,

    I'm studing the memory management of Xen, I noticed the Domain0
kernel(Linux) declared its features in the .section __xen_guest, just like
this:

 

/*linux-2.6-xen-sparse/arch/i386/kernel/head-xen.S*/

         .ascii  ",FEATURES=writable_page_tables"

         .ascii                  "|writable_descriptor_tables"

         .ascii                  "|auto_translated_physmap"

         .ascii                  "|pae_pgdir_above_4gb"

         .ascii                  "|supervisor_mode_kernel"

 

   All these features information will be parsed by xen before the domain0
kernel image was loaded, and I noticed when the hypervisor responded to the
HYPERVISOR_xen_version(XENVER_get_features, &fi) hypercall of domain0, it
will check the PG_translate and PG_SH_enable flags of d->arch.paging.mode of
the calling domain to determine how to fill the output parameter fi, just
like this:

 

/*xen/common/kernel.c*/

if ( shadow_mode_translate(current->domain) )

                fi.submap |= 

                    (1U << XENFEAT_writable_page_tables) |

                    (1U << XENFEAT_auto_translated_physmap);

 

    and domain0 kernel will use this information to determine how to set its
own feature flags, and whether to do the p2m and m2p translation between pfn
and mfn, the following is an example:

 

/*linux-2.6-xen-sparse/include/asm-i386/mach-xen/asm/maddr.h */

static inline unsigned long pfn_to_mfn(unsigned long pfn)

{

         if (xen_feature(XENFEAT_auto_translated_physmap))

                   return pfn;

         BUG_ON(max_mapnr && pfn >= max_mapnr);

         return phys_to_machine_mapping[pfn] & ~FOREIGN_FRAME_BIT;

} 

 

    What I want to know is whether there are some relationship between the
auto_translated_physmap feature and the shadow_mode_translate mode of
domain, do they have the same meaning? I think this feature will work(Guest
kernel do the p2m and m2p translation) only when the shadow mode of domain
is enabled, but this is not true for domain0 because it's a paravirtualized
domain, why did it still declare this feature? I am looking forward to your
response, thank you very much.

 

 

Regards,

HUYanyan

 


[-- Attachment #1.2: Type: text/html, Size: 9989 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: relationship of the auto_translated_physmap feature and the shadow_mode_translate mode of domain

[Tim Deegan]

At 22:45 +0800 on 30 May (1212187536), HuYanyan wrote:
>     What I want to know is whether there are some relationship between the
> auto_translated_physmap feature and the shadow_mode_translate mode of
> domain, do they have the same meaning?

They have almost the same meaning.  shadow_mode_translate means that 
the domain is using shadow pagetables and that the shadow pagetable code
is responsible for handling the translation from guest-physical to
machine-physical addresses.  HVM guests always run in this mode; by
default, PV guests don't run under shadow pagetables at all, except
during live migration, and even then they do their own translation.

auto_translated_physmap is a PV guest feature flag that requires the
guest to be run in shadow_mode_translate.

BUT: the code for running PV guests in shadow_mode_translate does not
work, as far as I know.  The last time anyone tried to make the
xen-unstable shadow code work in this configuration was more than a year
ago.

> I think this feature will work(Guest
> kernel do the p2m and m2p translation) only when the shadow mode of domain
> is enabled, but this is not true for domain0 because it's a paravirtualized
> domain, why did it still declare this feature? 

It was useful for some research projects to be able to change the p2m
without altering the guest's state, when doing things like execution
replay.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

re: relationship of the auto_translated_physmap feature and the shadow_mode_translate mode of domain

[Hu Yanyan]

[-- Attachment #1.1: Type: text/plain, Size: 3274 bytes --]

Hi Tim.

    Thank you very much for your response, it helps me a lot. I read the
code of the setup_xen_features function and related hypercall processing
routine last weekend, and it's very clear to me now, thanks again.

 

Best Regards

HuYanyan

 


From: Tim Deegan <Tim.Deegan@citrix.com>
Date: Jun 2, 2008 4:38 PM
Subject: Re: [Xen-devel] relationship of the auto_translated_physmap feature
and the shadow_mode_translate mode of domain
To: HuYanyan <huyanyan@les.buaa.edu.cn>
Cc: xen-devel@lists.xensource.com

 


At 22:45 +0800 on 30 May (1212187536), HuYanyan wrote:
>     What I want to know is whether there are some relationship between the
> auto_translated_physmap feature and the shadow_mode_translate mode of
> domain, do they have the same meaning?

They have almost the same meaning.  shadow_mode_translate means that
the domain is using shadow pagetables and that the shadow pagetable code
is responsible for handling the translation from guest-physical to
machine-physical addresses.  HVM guests always run in this mode; by
default, PV guests don't run under shadow pagetables at all, except
during live migration, and even then they do their own translation.

auto_translated_physmap is a PV guest feature flag that requires the
guest to be run in shadow_mode_translate.

BUT: the code for running PV guests in shadow_mode_translate does not
work, as far as I know.  The last time anyone tried to make the
xen-unstable shadow code work in this configuration was more than a year
ago.

> I think this feature will work(Guest
> kernel do the p2m and m2p translation) only when the shadow mode of domain
> is enabled, but this is not true for domain0 because it's a
paravirtualized
> domain, why did it still declare this feature?

It was useful for some research projects to be able to change the p2m
without altering the guest's state, when doing things like execution
replay.

Cheers,

Tim.

--
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

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



-- 
Best wishes

杨漾
北京航空航天大学计算机学院体系结构研究所
电话:010-82338059-132
邮件:9907yruby@gmail.com
地址：北京市海淀区学院路37号北京航空航天大学新主楼 G座1026
----------------------------------------------------------------------------
----
Yang Yang
Institute of Computer Architecture and System 
BeiHang University（BUAA）
Tel: (86-10)82338059-132
Email: 9907yruby@gmail.com
Addr: Room 1026,Building G,The New Main Building,37# Xueyuan Rd.,Haidian
District, Beijing 100083, PRC 

-- 
Best wishes

杨漾
北京航空航天大学计算机学院体系结构研究所
电话:010-82338059-132
邮件:9907yruby@gmail.com
地址：北京市海淀区学院路37号北京航空航天大学新主楼 G座1026
----------------------------------------------------------------------------
----
Yang Yang
Institute of Computer Architecture and System 
BeiHang University（BUAA）
Tel: (86-10)82338059-132
Email: 9907yruby@gmail.com
Addr: Room 1026,Building G,The New Main Building,37# Xueyuan Rd.,Haidian
District, Beijing 100083, PRC 


[-- Attachment #1.2: Type: text/html, Size: 8181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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