[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86: add hypercall to query currentunderlying pCPU's frequency

  • To: Jan Beulich <jbeulich@xxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Mon, 22 Sep 2008 09:47:28 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 22 Sep 2008 01:49:03 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Ackcj9ecFk2a2oiDEd2psAAX8io7RQ==
  • Thread-topic: [Xen-devel] [PATCH] x86: add hypercall to query currentunderlying pCPU's frequency

Well, I'm not personally against this, if used sensibly, but it sounds the
sort of thing the Advisory Board would have to be asked about, since it
could be considered to promote forking of the hypervisor interfaces.

 -- Keir

On 22/9/08 08:55, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> Okay, in that case I'll have to raise a general infra-structural question: If
> I'm convinced I/we want something like this for ease of use and consistency
> with the native kernel, how would I (generally) add (sub-)hypercalls to
> our Xen flavors without risking to ever collide with upstream? I'd consider
> something like using (reserving) the number space starting with e.g. ASCII
> 'NW' (a traditional Novell prefix) in the upper 16 bits, but of course I'd
> want to have formal insurance that this range would actually remain
> reserved forever within each (sub-)hypercall ranges (and whatever else
> may use [pseudo-]enumerated values).
> Another alternative would obviously be to simply once again use an
> enumeration of interested parties, who would then have a certain number
> range globally (across all other [pseudo-]enumerations) reserved for their
> purposes, i.e. with the upper so-many bits set to that 'vendor' enumerator.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.