On Mon, 2006-06-26 at 20:28 +0100, Ewan Mellor wrote:
> On Mon, Jun 26, 2006 at 01:31:24PM -0500, Hollis Blanchard wrote:
>
> > [Snip: Re: CPU feature flags]
> >
> > 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.")
>
> The other use case is "Please don't expose these features to my VM, because I
> will need to be able to move it over there later".
That would be pretty easy with opaque types if the later host exists as
part of the managed cluster already: at creation time, you could
indicate the set of hosts you will ever want to run the domain on.
If you want to specify hypothetical hosts though, I guess you'd want
some sort of checkbox system, i.e. "Pick the following CPU types you
want to be able to run this domain on." The UI would translate e.g. "AMD
Elan SC520" into a particular set of feature bits.
> > Also, do you expect non-specialist users to manage terms like "CX8",
> > "PSE36", ...?
>
> That's a good question, but one I hope to solve at the UI, not the API. Maybe
> your cluster manager knows what machines you have in your hetrogenous cluster,
> and so can manage these flags for you?
>
> > - 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?
>
> I expect us to define a set of strings that are known and understood to have
> particular semantics, so that higher level software can manage them. I don't
> think that we can manage these flags correctly otherwise. I don't see this as
> a problem for portability -- I hope to be able to define the appropriate
> strings for PPC as well as for x86. For flags that we don't yet know about,
> for platforms that we're not working with at the moment, say, or new flags on
> existing platforms, we would add these to the set of known strings. New
> clients would be fine -- old clients would have to say to the user "I've no
> idea what this value 'PSE79' is, should I leave it alone?" (or the client
> software could just leave it alone silently).
My concern is that the API users (i.e. the management software) will
need to know intimate details about processors, and I don't trust them
to think about portability. :) I'd prefer to have an API that you simply
can't misuse.
> > - 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.
>
> On the wire, a particular value of an enum is a string, yes.
So we're clear: do you mean "0x1234" will be the string "on the wire",
or do you mean "CX8,PSE36,FPU"?
Actually, that may not matter (assuming the protocol can handle
arbitrarily-sized integers). I just checked, and it looks like there is
a lot of room for capability bits (I'm looking at DOM0_PHYSINFO and
__HYPERVISOR_xen_version [the distinction there is not obvious to me]).
However, I still don't think it makes sense to include bits from all
possible architectures in the same namespace, but rather reuse bit
positions for each architecture. In other words, capability bit 0 on x86
could mean something different from capability bit 0 on ia64.
> > - Do you agree that it makes sense to add "architecture" and "compatible
> > architectures" fields to class VM and host_cpu, respectively?
>
> I certainly agree that we need to handle non-x86 platforms, but I'm not sure
> what that entails.
>
> I don't have a problem adding "architecture" to VM, that sounds like something
> you'd want to know anyway. Does having "compatible architectures" on the
> Host_cpu class make sense, as opposed to having it on Host? Do we want to
> model a machine with different CPU architectures?
Ah, I'd missed Host. Yes, it makes more sense there than on Host_cpu.
> If we fix these things, are these fields sufficient for PPC support?
I don't want to officially sign off on anything, but I think so. :) I'd
particularly like to see higher-level software using this API. (I think
in general it's hard to get an API right without seeing a couple users
first.)
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home