para virt cpuid?

para virt cpuid?

[aq]

hello,

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? 

regards,
aq

RE: para virt cpuid?

[Ian Pratt]

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

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.

Ian

Re: para virt cpuid?

[Dave Jones]

On Tue, Jun 07, 2005 at 12:15:17PM +0100, Ian Pratt wrote:
 > > 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
 > directly.

Either that, or they parse /dev/cpu/N/cpuid, which is again, trappable by
the kernel if we so desired. Any apps that do cpuid instruction calls
itself is likely broken anyway on SMP machines, unless it also plays
games with the scheduler affinity calls.

		Dave

Re: para virt cpuid?

[Jan Schneider]

Ian Pratt <m+Ian.Pratt <at> cl.cam.ac.uk> writes:
> 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.

That shouldn't be too important, because migrations between different cpu's isn't
exactly what will be done in production environments.
So a simple global check that source-xen-hostA has the same cpu-featureset as
target-xen-hostB should be enough.
Xen should than issue a warning that the migration-target is equipped with a
different cpu/cpu-feautureset.
A check hat tracks used features would be slightly overkill, also it could be an
additional error-source.
I think KISS would be the right way for this topic.
Of course thats an personal opininion out of a production environment ;).