Hi Alex:
Wing's patch seems fine on my system. I do a little change, you can have a try
now.
Best regards,
Ronghui
>-----Original Message-----
>From: Zhang, Xing Z
>Sent: Friday, November 23, 2007 1:27 PM
>To: Alex Williamson
>Cc: xen-ia64-devel; Duan, Ronghui
>Subject: RE: [Xen-ia64-devel] [xen-ia64][PATCH]New set OS type method
>
>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.
ident_map_opt.patch
Description: ident_map_opt.patch
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home