This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-API] Xen Management API draft - portability

To: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Subject: Re: [Xen-API] Xen Management API draft - portability
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Mon, 26 Jun 2006 13:31:24 -0500
Cc: Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 26 Jun 2006 11:31:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060625094844.GD24879@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM Linux Technology Center
References: <20060622170130.GI25606@xxxxxxxxxxxxxxxxxxxxxx> <1151001252.2599.65.camel@xxxxxxxxxxxxxxxxxxxxx> <20060625094844.GD24879@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
On Sun, 2006-06-25 at 10:48 +0100, Ewan Mellor wrote:
> 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.

Sorry, this still isn't clear to me.

> 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.

I think a free-form string would be best.

> > 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"?
> 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".

(I don't understand your bitmask example...)

I didn't realize these features will be exposed in the user interface at
all. How do you expect that to work? (I explained the only scenario that
I could see: "I created a domain here, and now I want to know if I can
move it over there.")

Also, do you expect non-specialist users to manage terms like "CX8",
"PSE36", ...?

> 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.


Now how about my other questions?
- Do you expect higher-level software to hardcode a list of these
features for the UI? That's a problem both for portability and for
future x86 architectures (with currently undefined feature bits). How
can we avoid that?
- Is an "enum" here a list of strings? If not, there is danger of
running out of bit numbers in a fixed-size bitmask. It's worth pointing
out that you've already listed 63 enum items.
- Do you agree that it makes sense to add "architecture" and "compatible
architectures" fields to class VM and host_cpu, respectively?

Hollis Blanchard
IBM Linux Technology Center

xen-api mailing list