[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Alex Williamson" <alex.williamson@xxxxxx>
  • From: "Zhang, Xing Z" <xing.z.zhang@xxxxxxxxx>
  • Date: Thu, 22 Nov 2007 00:44:45 +0800
  • Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 21 Nov 2007 08:45:18 -0800
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcgsRu2SkLDjnfrfSwW/h2VSGWQyNgAEreWw
  • Thread-topic: [Xen-ia64-devel] [xen-ia64][PATCH]New set OS type method

>
>   Thanks for looking into this.  Your implementation is kind
>of along
>the lines I was thinking.  Would it make more sense to represent
>Guest_os_type as a fixed length string?  There's no reason to
>stay with
>the 0xBx specification if we're doing this through the config
>file (and
>as a user, its unnecessarily complicated).  The down side is
>that it
>gives the user more opportunity to make a mistake, but I think
>if we
>give the known useful values in the example file it should be
>ok.  We'll
>have to work with upstream on a config variable that might be
>generically useful to others.

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.

>
>   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?

>
>   BTW, I see your e100 driver is now in upstream.  Good work!
>I'll
>merge that in and try it.  Thanks again for looking at this.
>
>       Alex
>
>--
>Alex Williamson                             HP Open Source & Linux
>Org.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.