On Thu, Jun 22, 2006 at 01:34:12PM -0500, Hollis Blanchard wrote:
> On Thu, 2006-06-22 at 18:01 +0100, Ewan Mellor wrote:
> > Attached is a draft Xen Management API. This document presents our ideas in
> > terms of a data model, with an implied binding to XML-RPC calls. There are
> > a
> > few examples in there too -- hopefully it's clear how the mapping between
> > the
> > document and the wire protocol.
>
> Hi, I'm concerned about some of the x86 assumptions in this document. In
> particular:
>
> enum bios_boot_option:
> Is this relevant outside of HVM? Perhaps both those "bios" fields in
> class VM could be replaced with a "boot device" string? Many non-x86
> systems specify boot devices with free text; they are not limited by
> legacy x86 BIOS. I believe that's even true for Intel's EFI.
IIRC, people have spoke in the past about using a "BIOS" even with paravirt
guests, as opposed to using pygrub for example, so I think that this is
potentially relevant outside of HVM. I wouldn't have a problem with making
these free-form strings instead, or providing a different field, if you think
you need extra flexibility.
> enum cpu_feature:
> Very concerned about this one. How is this supposed to be used? If
> higher-level code uses constants like "PAE", that software will need
> modification for every non-x86 architecture, and I think that should be
> an anti-goal. What makes sense to me is if Xen passes up an *opaque*
> bitmask specifying required features (hcall: "what features does domain
> 7 require?"), and that bitmask could be passed back down to Xen e.g.
> when migrating a VM (hcall: "do you support these features?").
> I see that IA64 has its own "feature" bit. When thinking about managing
> a heterogeneous cluster of Xen systems, it would probably make more
> sense to have an "architecture" field in class VM. Then we could add a
> "compatible architectures" field to class host_cpu, i.e. a list of
> architectures that CPU can support. For an x86-64 CPU, that would be
> "x86, x86-64". That way, when looking for a system on which to start an
> x86 VM, the user could be presented with a list of all x86 and x86-64
> systems being managed.
> Each architecture needs its own "optional feature" values, but there's
> no sense in putting them all into the same namespace. For example,
> PowerPC would have an FPU bit, but also Altivec, and of course almost
> none of the x86 bits listed would be relevant for us, so it's a waste of
> bits. I'm sure IA64 has the same situation.
> Of course, there are already a lot of bits in this list; it's
> conceivable we could run out of bits in an int/long/whatever in the
> future. Would it be better to communicate required features as strings
> instead of an enum? Or am I misunderstanding, and the "enums" in this
> document do not mean the same as "enum" in C, instead meaning "list of
> acceptable string values"?
>
> Those are the first issues that stand out for me. In general I'd like to
> remind everybody that computer networks are not homogeneous, so let's
> not box ourselves into a corner in the future by designing an
> x86-specific API today... :)
The constants in cpu_feature are taken from Linux's
include/asm-i386/cpufeature.h. It's obviously x86-specific at the moment, and
if that's a problem, then we can work on it.
If there are fields that only make sense on x86, I don't have a problem with
that -- they can just be ignored on other, more sensible, platforms, as long
as we've got the capacity to manage x86's idiosyncrasies. On the other hand,
if the problem needs to be solved on other arches too, then we should put
together a platform-agnostic API.
I can see the appeal of using opaque bitstrings, but I'm worried that these
will be unmanagable by non-specialist users. We can't very well say to people
"look up the CPU features for your particular platforms, AND them together,
and then type the resultant bitmask here". We need to be able to provide a
meaningful mapping at the API level, which is why it would be nice to use an
enum. Perhaps a list of strings would be the best compromise -- we could
define the strings that make sense on any particular platform, and the API
would remain flexible for the future.
Ewan.
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home