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

RE: [Xen-devel] para virt cpuid?

  • To: "aq" <aquynh@xxxxxxxxx>, "Xen Dev" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Tue, 7 Jun 2005 12:15:17 +0100
  • Delivery-date: Tue, 07 Jun 2005 11:14:26 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcVrTmyyrY6ntm2DQH2PCk7bs6o/kQAANy7g
  • Thread-topic: [Xen-devel] para virt cpuid?

> looking at TODO list, i see this stuff: "para virt cpuid
> (/proc/cpuinfo) allow hiding from domains via domain config"
> I dont understand what it is. Anybody here could explain this to me? 

Unfortunately, its not possible to trap the cpuid instruction on
standard x86. Which makes it hard to 'hide' certain processor features
from applications and libraries (since we're hacking the kernel we can
get around this inside the kernel).

You may wish to hide certain features from user applications such that
you can migrate the VM to a different host without worrying whether it
has that feature or not (e.g. migrating from an SSE2 host to one that
doesn't have it).

Some applications decide whether they can use a CPU feature by reading
from /proc/cpuinfo, in which case we could hide features under the
control of the domain's config. Unfortunately, I fear many (most?)
application libraries probably just go at the cpuid instruction

For some cpu features it may be possible to take a trap the first time
they are used, and hence 'taint' the domain with a marker that says it
can only be migrated to hosts that support the feature. I haven't
thought through how widely this technique would work, though. We
probably need to go through and audit all the post Pentium Pro features
and decide a) whther they're visable to user space b) whether a trap can
be generated on first use.


Xen-devel mailing list



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