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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 ;). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel