>-----Original Message-----
>From: Duan, Ronghui
>Sent: Monday, November 26, 2007 4:42 PM
>To: Zhang, Xing Z; 'Alex Williamson'
>Cc: 'xen-ia64-devel'
>Subject: RE: [Xen-ia64-devel] [xen-ia64][PATCH]New set OS type method
>
>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_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
|
Home