RE: [Xen-ia64-devel] [xen-ia64][PATCH]New set OS type method

["Zhang, Xing Z" <xing.z.zhang@xxxxxxxxx>]

Hi Alex:
        These patches are per your comments. I do string to magic number 
translation in IA64 child class so that it doesn't impact on common code. 
        Unfortunately, a python code block this patch.

+ xc.hvm_set_param(self.vm.getDomid(),HVM_PARAM_GOS_TYPE, val)
   It always reports "invalid argument". I didn't get the cause.
   I am afraid I can't go on debugging it because of my graduate thesis. 
Fortunately, Ronghui will continue my work. Many thanks to Ronghui.

Good good study,day day up ! ^_^
-Wing(zhang xin)

OTC,Intel Corporation

>-----Original Message-----
>From: Alex Williamson [mailto:alex.williamson@xxxxxx]
>Sent: 2007?11?22? 1:27
>To: Zhang, Xing Z
>Cc: xen-ia64-devel
>Subject: RE: [Xen-ia64-devel] [xen-ia64][PATCH]New set OS type
>method
>
>
>On Thu, 2007-11-22 at 00:44 +0800, Zhang, Xing Z wrote:
>> In the beginning, I used the method that let user set a
>> string(windows/linux) in script file. Since Xend will call
>> xc_hvm_set_param(It only accepts a u64 parameter) to pass
>parameter to
>> HV, we must translate string(windows/linux) to a magic number
>in Xend.
>> The string-number pair has to be defined as constants in python
>file.
>> This increases modifications of common code. I am afraid
>community may
>> not happy to see it.
>> If you prefer string parameter way, I'd like to post another
>patch.
>> It's easy to do.
>
>Hi Wing,
>
>   I think this can probably still be done without significant
>common
>code changes.  The encoding of the string to a u64 is the tricky
>part.
>Perhaps we should use the u64 as a unsigned char[8] and simply
>write a
>string to it.  This could then leave it to architecture builder
>code as
>to how to interpret the string as you have below.  That would
>still
>allow it to be generally useful to x86 at some point in the future
>too.
>
>> >   The other question is whether we parse the string in Xen
>or
>> >in the
>> >domain builder tools.  For instance, the tools might parse
>> >"Windows" and
>> >set flags that regions 4 & 5 are identity mapped instead of
>just
>> >passing
>> >that "Windows" string into Xen.  I don't know if this really
>> >adds
>> >anything or just keeps string parsing out of Xen.
>>
>> I am not sure I get your meaning. Do you mean we parse OS type
>in
>> Xend, then directly tell Xen to do corresponding optimization?
>If so,
>> there is a hypercall named __HYPERVISOR_opt_feature in
>hypercall.c. We
>> can change current implementation  to below flow:
>>
>> Xend parse string parameter -------> xc_set_hvm_param()
>record OS type
>> temporarily --------> xc_ia64_hvm_build() call
>xc_get_hvm_param() to
>> get OS type -------> call __HYPERVISOR_opt_feature to set
>> corresponding optimization in Xen
>>
>> The purpose to use xc_set_hvm_param/xc_get_hvm_param here is
>avoid
>> adding a new interface in xc lib, because we need pass OS type
>to
>> domain building function in libxc.
>>
>> This is also easy to do. Which you prefer?
>
>   Yes, this sounds more like what I'm thinking.  Something
>like:
>
>xmexample.vti:
># guest_os_string (optional)
># Specify the OS running in the guest domain, this may enable
># optimization features for the specified OS type.  Other OSes
># may not run correctly if the wrong OS type is specified.
>#
># Default is "default", which should work for all supported
>guest OSes.
>#
># Known values:
>#    "linux" - All Linux variants
>#    "windows" - All Windows variants (Windows Server
>2003/2008)
>#
># guest_os_string="default"
>
>Xend would effectively snprintf() this string into a u64, and
>store it
>with xc_set_hvm_param() - Perhaps HVM_PARAM_OS_STRING?  Then
>as you
>outline, the ia64 builder would get the param, and make
>individual
>opt_feature calls to explicitly set the identity mapped
>regions.
>
>   One potential issue with this is that we're setting the
>optimization
>before the guest runs this way.  I don't think this is a problem
>for
>linux as it maintains the same identity mapped regions from the
>first
>jump into virtual mode.  However, I don't know about Windows.
>I've
>heard it jumps in and out of physical mode multiple times in
>the boot
>loader, is it going to be ok w/ this optimization on through
>all of
>those?  Thanks,
>
>       Alex
>
>--
>Alex Williamson                             HP Open Source & Linux
>Org.

Attachment: ident_map_opt.patch
Description: ident_map_opt.patch

Attachment: ident_map_opt_for_dom0.patch
Description: ident_map_opt_for_dom0.patch

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