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

[Alex Williamson <alex.williamson@xxxxxx>]

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.


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