[PATCH] Create XEN_DOMCTL_set_opt_feature

[PATCH] Create XEN_DOMCTL_set_opt_feature

[Alex Williamson]

[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]


   This patch goes along with the guest_os_type domain config patch.
Once we know what the guest OS is in the builder code, we need a
mechanism to set optimization features for that guest.  This is done via
a new XEN_DOMCTL as shown in the patch below.  This only has ia64
specific contents at the moment, but could be expanded for x86.  I
expect the contents of the structure will mostly be architecture
specific.  Thanks,

	Alex

Xen patch below, identical patch for xenlinux attached.

Signed-off-by: Alex Williamson <alex.williamson@hp.com>
---

diff -r c555a5f97982 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Wed Nov 28 13:36:56 2007 +0000
+++ b/xen/include/public/domctl.h	Wed Nov 28 10:19:31 2007 -0700
@@ -539,6 +539,17 @@ typedef struct xen_domctl_ext_vcpucontex
 typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_ext_vcpucontext_t);
 
+/*
+ * Set optimizaton features for a domain
+ */
+#define XEN_DOMCTL_set_opt_feature    44
+struct xen_domctl_set_opt_feature {
+#ifdef __ia64__
+    struct xen_ia64_opt_feature optf;
+#endif
+};
+typedef struct xen_domctl_set_opt_feature xen_domctl_set_opt_feature_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_opt_feature_t);
 
 struct xen_domctl {
     uint32_t cmd;
@@ -575,6 +586,7 @@ struct xen_domctl {
         struct xen_domctl_ioport_mapping    ioport_mapping;
         struct xen_domctl_pin_mem_cacheattr pin_mem_cacheattr;
         struct xen_domctl_ext_vcpucontext   ext_vcpucontext;
+        struct xen_domctl_set_opt_feature   set_opt_feature;
         uint8_t                             pad[128];
     } u;
 };


[-- Attachment #2: XEN_DOMCTL_set_opt_feature-linux.patch --]
[-- Type: text/x-patch, Size: 1108 bytes --]

diff -r fd879c0688bf include/xen/interface/domctl.h
--- a/include/xen/interface/domctl.h	Fri Nov 23 16:26:56 2007 +0000
+++ b/include/xen/interface/domctl.h	Wed Nov 28 10:23:06 2007 -0700
@@ -539,6 +539,17 @@ typedef struct xen_domctl_ext_vcpucontex
 typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_ext_vcpucontext_t);
 
+/*
+ * Set optimizaton features for a domain
+ */
+#define XEN_DOMCTL_set_opt_feature    44
+struct xen_domctl_set_opt_feature {
+#ifdef __ia64__
+    struct xen_ia64_opt_feature optf;
+#endif
+};
+typedef struct xen_domctl_set_opt_feature xen_domctl_set_opt_feature_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_opt_feature_t);
 
 struct xen_domctl {
     uint32_t cmd;
@@ -575,6 +586,7 @@ struct xen_domctl {
         struct xen_domctl_ioport_mapping    ioport_mapping;
         struct xen_domctl_pin_mem_cacheattr pin_mem_cacheattr;
         struct xen_domctl_ext_vcpucontext   ext_vcpucontext;
+        struct xen_domctl_set_opt_feature   set_opt_feature;
         uint8_t                             pad[128];
     } u;
 };

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH] Create XEN_DOMCTL_set_opt_feature

[Keir Fraser]

On 28/11/07 17:31, "Alex Williamson" <alex.williamson@hp.com> wrote:

>    This patch goes along with the guest_os_type domain config patch.
> Once we know what the guest OS is in the builder code, we need a
> mechanism to set optimization features for that guest.  This is done via
> a new XEN_DOMCTL as shown in the patch below.  This only has ia64
> specific contents at the moment, but could be expanded for x86.  I
> expect the contents of the structure will mostly be architecture
> specific.  Thanks,

If you use this in the builder, why do you need a hvm param at all? In any
case I don't like the encoding of OS strings into hvm_param integers. Either
the concept of 'OS type' should not be visible to Xen, or a proper
enumeration should be defined, or if you want a string then the builder
should stick it in memory for your virtual boot firmware to pick up.

 -- Keir

Re: [PATCH] Create XEN_DOMCTL_set_opt_feature

[Daniel P. Berrange]

On Wed, Nov 28, 2007 at 05:39:31PM +0000, Keir Fraser wrote:
> On 28/11/07 17:31, "Alex Williamson" <alex.williamson@hp.com> wrote:
> 
> >    This patch goes along with the guest_os_type domain config patch.
> > Once we know what the guest OS is in the builder code, we need a
> > mechanism to set optimization features for that guest.  This is done via
> > a new XEN_DOMCTL as shown in the patch below.  This only has ia64
> > specific contents at the moment, but could be expanded for x86.  I
> > expect the contents of the structure will mostly be architecture
> > specific.  Thanks,
> 
> If you use this in the builder, why do you need a hvm param at all? In any
> case I don't like the encoding of OS strings into hvm_param integers. Either
> the concept of 'OS type' should not be visible to Xen, or a proper
> enumeration should be defined, or if you want a string then the builder
> should stick it in memory for your virtual boot firmware to pick up.

I agree. The concept of 'OS type' has no business being present in the
hypervisor/low level APIs at all.  That is an end-user facing concept,
which high level management tools translate to a specific set of low
level features/capabilities. The hypervisor / low level APIs should 
have explicit features/capabilities.  

eg, virt-manager has a concept of OS type - if you choose 'Windows' it
will pass appropriate config to XenD to add a USB tablet, set QEMU to 
'localtime', and a handful of other things. 

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: [PATCH] Create XEN_DOMCTL_set_opt_feature

[Alex Williamson]

On Wed, 2007-11-28 at 17:39 +0000, Keir Fraser wrote:
> On 28/11/07 17:31, "Alex Williamson" <alex.williamson@hp.com> wrote:
> 
> >    This patch goes along with the guest_os_type domain config patch.
> > Once we know what the guest OS is in the builder code, we need a
> > mechanism to set optimization features for that guest.  This is done via
> > a new XEN_DOMCTL as shown in the patch below.  This only has ia64
> > specific contents at the moment, but could be expanded for x86.  I
> > expect the contents of the structure will mostly be architecture
> > specific.  Thanks,
> 
> If you use this in the builder, why do you need a hvm param at all? In any
> case I don't like the encoding of OS strings into hvm_param integers. Either
> the concept of 'OS type' should not be visible to Xen, or a proper
> enumeration should be defined, or if you want a string then the builder
> should stick it in memory for your virtual boot firmware to pick up.

Hi Keir,

   You're right, thanks for bringing it to my attention that storing it
in an hvm_param is simply unnecessary.  If we add the guest_os_type
config option as per the new patch below, and still add the
XEN_DOMCTL_set_opt_feature call, everything else can be done in
architecture code.  I'll make a pyxc binding to an xc_ia64_set_os_type
that gets passed self.guest_os_type and makes use of set_opt_feature.
This avoids munging the string into an integer entirely and keeps
guest_os_type out of Xen.  Does this look more reasonable?  Please also
apply this and the original XEN_DOMCTL_set_opt_feature patch if so.
Thanks,

	Alex

Signed-off-by: Alex Williamson <alex.williamson@hp.com>
---

diff -r c555a5f97982 tools/python/xen/xend/XendConfig.py
--- a/tools/python/xen/xend/XendConfig.py	Wed Nov 28 13:36:56 2007 +0000
+++ b/tools/python/xen/xend/XendConfig.py	Wed Nov 28 09:48:59 2007 -0700
@@ -129,7 +129,8 @@ XENAPI_PLATFORM_CFG = [ 'acpi', 'apic', 
                         'nographic', 'pae', 'rtc_timeoffset', 'serial', 'sdl',
                         'soundhw','stdvga', 'usb', 'usbdevice', 'vnc',
                         'vncconsole', 'vncdisplay', 'vnclisten', 'timer_mode',
-                        'vncpasswd', 'vncunused', 'xauthority', 'pci', 'vhpt']
+                        'vncpasswd', 'vncunused', 'xauthority', 'pci', 'vhpt',
+                        'guest_os_type' ]
 
 # Xen API console 'other_config' keys.
 XENAPI_CONSOLE_OTHER_CFG = ['vncunused', 'vncdisplay', 'vnclisten',
diff -r c555a5f97982 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py	Wed Nov 28 13:36:56 2007 +0000
+++ b/tools/python/xen/xend/image.py	Wed Nov 28 11:22:38 2007 -0700
@@ -426,6 +426,7 @@ class HVMImageHandler(ImageHandler):
 
         self.apic = int(vmConfig['platform'].get('apic', 0))
         self.acpi = int(vmConfig['platform'].get('acpi', 0))
+        self.guest_os_type = vmConfig['platform'].get('guest_os_type')
 
     # Return a list of cmd line args to the device models based on the
     # xm config file
diff -r c555a5f97982 tools/python/xen/xm/create.py
--- a/tools/python/xen/xm/create.py	Wed Nov 28 13:36:56 2007 +0000
+++ b/tools/python/xen/xm/create.py	Wed Nov 28 09:48:59 2007 -0700
@@ -453,6 +453,10 @@ gopts.var('usbdevice', val='NAME',
 gopts.var('usbdevice', val='NAME',
           fn=set_value, default='',
           use="Name of USB device to add?")
+
+gopts.var('guest_os_type', val='NAME',
+          fn=set_value, default='default',
+          use="Guest OS type running in HVM")
 
 gopts.var('stdvga', val='no|yes',
           fn=set_bool, default=0,
@@ -733,7 +737,9 @@ def configure_hvm(config_image, vals):
              'localtime', 'serial', 'stdvga', 'isa', 'nographic', 'soundhw',
              'vnc', 'vncdisplay', 'vncunused', 'vncconsole', 'vnclisten',
              'sdl', 'display', 'xauthority', 'rtc_timeoffset', 'monitor',
-             'acpi', 'apic', 'usb', 'usbdevice', 'keymap', 'pci' ]
+             'acpi', 'apic', 'usb', 'usbdevice', 'keymap', 'pci',
+             'guest_os_type']
+
     for a in args:
         if a in vals.__dict__ and vals.__dict__[a] is not None:
             config_image.append([a, vals.__dict__[a]])

Re: [PATCH] Create XEN_DOMCTL_set_opt_feature

[Keir Fraser]

On 28/11/07 18:39, "Alex Williamson" <alex.williamson@hp.com> wrote:

>    You're right, thanks for bringing it to my attention that storing it
> in an hvm_param is simply unnecessary.  If we add the guest_os_type
> config option as per the new patch below, and still add the
> XEN_DOMCTL_set_opt_feature call, everything else can be done in
> architecture code.  I'll make a pyxc binding to an xc_ia64_set_os_type
> that gets passed self.guest_os_type and makes use of set_opt_feature.
> This avoids munging the string into an integer entirely and keeps
> guest_os_type out of Xen.  Does this look more reasonable?  Please also
> apply this and the original XEN_DOMCTL_set_opt_feature patch if so.

Yes, this sounds fine to me.

 -- Keir