Alex Williamson
2007-Nov-28 17:31 UTC
[Xen-devel] [PATCH] Create XEN_DOMCTL_set_opt_feature
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;
};
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2007-Nov-28 17:39 UTC
Re: [Xen-devel] [PATCH] Create XEN_DOMCTL_set_opt_feature
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel P. Berrange
2007-Nov-28 17:44 UTC
Re: [Xen-devel] [PATCH] Create XEN_DOMCTL_set_opt_feature
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 -=| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Alex Williamson
2007-Nov-28 18:39 UTC
Re: [Xen-devel] [PATCH] Create XEN_DOMCTL_set_opt_feature
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]]) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Nov-28 19:00 UTC
[Xen-ia64-devel] Re: [Xen-devel] [PATCH] Create XEN_DOMCTL_set_opt_feature
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 _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel