RE: Status of auto_translated_mode

RE: Status of auto_translated_mode

[Ian Pratt]

> Hi, Keir,
> 	Per agreement on last xen summit, now xen/ia64 
> community is working on moving dom0 from current p==m model 
> to p!=m model. First an easy way is chosen by Isaku that 
> physmap is invisible to dom0 which is instead managed by Xen. 
> After some investigation, we found that existing 
> auto_translated_mode matches our model and then would like to 
> know the status of this mode on xen/x86.
> 
> 1. First a background question, what's the major usage model 
> for auto_translated_mode? 
 
Currently, the main usage model is to support guests that haven't got
fully paravirtualied mm systems. It's also useful for a number of
research projects, such as vm fork, determinsitic replay etc.

> 2. Is auto_translated_mode only used for domU? Seems this 
> model can't apply to modified DMA interface since mfn is 
> required to manipulate physical devices.

It's currently only used for domU's, and needs to be extended to support
lookup of mfn's for DMA addresses, and to enable the backend drives to
work.

> 3. Does anyone exercise this mode recently? Is this logic 
> working or broken?

Definitely working.

> 	We'd like to know which areas need to be enhanced if 
> this translated mode can be applied to dom0. That would save 
> people much time since virtual drivers together with grant 
> table have been tuned to accommodate this mode. Then this 
> translated mode may be made more generic. :-)

The first thing I would do is get physcial device access working from
for a auto_translate guest.

Ian

Re: Status of auto_translated_mode

[Jesper Kristensen]

Ian Pratt wrote:

>>After some investigation, we found that existing 
>>auto_translated_mode matches our model and then would like to 
>>know the status of this mode on xen/x86.
>>
>>1. First a background question, what's the major usage model 
>>for auto_translated_mode? 
>>    
>>
> 
>Currently, the main usage model is to support guests that haven't got
>fully paravirtualied mm systems. It's also useful for a number of
>research projects, such as vm fork, determinsitic replay etc.
>
>  
>
A quick question: Can this be enabled on a per domU basis and how is 
this done correctly? The furthest I can track it is in 
tools/libxc/xc_linux_build.c

    shadow_mode_enabled = 
test_feature_bit(XENFEAT_auto_translated_physmap, required_features);

one could of course for now hardcode shadow_mode_enabled to 1, but it 
sounds like there would be a config file option for this kind of thing. 
I can not seem to backtrack this any further. So my question is this: 
how do I enable translated shadow mode as cleanly as possible?

Best Regards,
Jesper Kristensen

Re: Status of auto_translated_mode

[Ian Campbell]

On Tue, 2006-03-28 at 16:01 +0200, Jesper Kristensen wrote:
> So my question is this: how do I enable translated shadow mode as cleanly as possible?

You can add "features = auto_translated_physmap" to the domU
configuration file, this filters down to the test_feature_bit() call
which you observed.

xen-unstable changeset 9002 introduced all this.

Ian.

Re: Status of auto_translated_mode

[Christian Limpach]

On 3/28/06, Jesper Kristensen <cableman@cs.aau.dk> wrote:
> A quick question: Can this be enabled on a per domU basis and how is
> this done correctly? The furthest I can track it is in
> tools/libxc/xc_linux_build.c
>
>     shadow_mode_enabled =
> test_feature_bit(XENFEAT_auto_translated_physmap, required_features);
>
> one could of course for now hardcode shadow_mode_enabled to 1, but it
> sounds like there would be a config file option for this kind of thing.
> I can not seem to backtrack this any further. So my question is this:
> how do I enable translated shadow mode as cleanly as possible?

You can either enable it by adding "FEATURES=!auto_translated_physmap"
to the xen_guest section of your kernel image or you can enable it
from the xm create command line or config file:
features=auto_translated_physmap.

     christian

RE: Status of auto_translated_mode

[Tian, Kevin]

>From: Jesper Kristensen
>Sent: 2006年3月28日 22:02
>Ian Pratt wrote:
>
>>>After some investigation, we found that existing
>>>auto_translated_mode matches our model and then would like to
>>>know the status of this mode on xen/x86.
>>>
>>>1. First a background question, what's the major usage model
>>>for auto_translated_mode?
>>>
>>>
>>
>>Currently, the main usage model is to support guests that haven't got
>>fully paravirtualied mm systems. It's also useful for a number of
>>research projects, such as vm fork, determinsitic replay etc.
>>
>>
>>
>A quick question: Can this be enabled on a per domU basis and how is
>this done correctly? The furthest I can track it is in
>tools/libxc/xc_linux_build.c
>
>    shadow_mode_enabled =
>test_feature_bit(XENFEAT_auto_translated_physmap,
>required_features);
>
>one could of course for now hardcode shadow_mode_enabled to 1, but it
>sounds like there would be a config file option for this kind of thing.
>I can not seem to backtrack this any further. So my question is this:
>how do I enable translated shadow mode as cleanly as possible?
>
>Best Regards,
>Jesper Kristensen

You can add a "features=" in your config file, which will be parsed and 
then passed to xc_linux_build.

Thanks,
Kevin

RE: Status of auto_translated_mode

[Tian, Kevin]

>From: Ian Pratt [mailto:m+Ian.Pratt@cl.cam.ac.uk]
>Sent: 2006年3月28日 20:33
>> 1. First a background question, what's the major usage model
>> for auto_translated_mode?
>
>Currently, the main usage model is to support guests that haven't got
>fully paravirtualied mm systems. It's also useful for a number of
>research projects, such as vm fork, determinsitic replay etc.

Thanks for clarification. Seems XENFEAT_supervisor_mode_kernel also 
serves for similar research purpose, right? :-)

>
>> 2. Is auto_translated_mode only used for domU? Seems this
>> model can't apply to modified DMA interface since mfn is
>> required to manipulate physical devices.
>
>It's currently only used for domU's, and needs to be extended to support
>lookup of mfn's for DMA addresses, and to enable the backend drives to
>work.

OK, then that's the areas xen/ia64 needs to solve since we want dom0 to 
run on top of this model.

>
>> 3. Does anyone exercise this mode recently? Is this logic
>> working or broken?
>
>Definitely working.

Great.

>
>> 	We'd like to know which areas need to be enhanced if
>> this translated mode can be applied to dom0. That would save
>> people much time since virtual drivers together with grant
>> table have been tuned to accommodate this mode. Then this
>> translated mode may be made more generic. :-)
>
>The first thing I would do is get physcial device access working from
>for a auto_translate guest.
>
>Ian

Yep.

Thanks,
Kevin

Status of auto_translated_mode

[Tian, Kevin]

Hi, Keir,
	Per agreement on last xen summit, now xen/ia64 community is
working on 
moving dom0 from current p==m model to p!=m model. First an easy way is
chosen 
by Isaku that physmap is invisible to dom0 which is instead managed by
Xen. After 
some investigation, we found that existing auto_translated_mode matches
our model 
and then would like to know the status of this mode on xen/x86.

1. First a background question, what's the major usage model for 
auto_translated_mode? 

2. Is auto_translated_mode only used for domU? Seems this model can't
apply to 
modified DMA interface since mfn is required to manipulate physical
devices.

3. Does anyone exercise this mode recently? Is this logic working or
broken?

	We'd like to know which areas need to be enhanced if this
translated mode can 
be applied to dom0. That would save people much time since virtual
drivers together 
with grant table have been tuned to accommodate this mode. Then this
translated 
mode may be made more generic. :-)

Thanks,
Kevin