On Wed, Nov 28, 2007 at 05:39:31PM +0000, Keir Fraser wrote:
> On 28/11/07 17:31, "Alex Williamson" <alex.williamson@xxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home