On Fri, Jun 15, 2007 at 12:27:01PM +0100, John Levon wrote:
On Fri, Jun 15, 2007 at 05:57:30AM -0400, Daniel Veillard wrote:
#include <xen/xen.h> +#ifdef __linux__ #include <xen/linux/privcmd.h> +#else +#include <xen/sys/privcmd.h> +#endif
In general I would prefer Solaris sections to not be defined as !linux but as a positive test on your platform macro, but in that case since it's a Xen path it's fine
I recently putback a change to install in xen/sys/* on Linux too. I think this will need to be a configure test at some point, to support older Xens. That is:
older Xen on Linux: linux/privcmd.h newer Xen on Linux: sys/privcmd.h Xen on Solaris: sys/privcmd.h
if we can solve this as configure test, that's perfect IMHO.
makes sense, so you changed the hypervisor to copy or pin the user data ?
Actually the dom0 kernel does this.
Hum, right that's not a direct call but ioctl :-)
+void +loadCapabilities(FILE *cpuinfo, FILE *capabilities, char *hvm_type, + int *host_pae, char *line, int LINE_SIZE) +{ + struct { + uint32_t r_eax, r_ebx, r_ecx, r_edx; + } _r, *rp = &_r; + int d, cmd; + char *s; + hypercall_t hc;
So that's arch dependant right ? Could you
In terms of cpuid, it works on Linux too, except that Linux has /dev/cpu/0/cpuid and we have /dev/cpu/self/cpuid. Also I don't think you can rely on the Linux driver being available.
Hum, I reacted to the names which to me were register names, and then I assumed this was arch specific, i.e. would generate problems say on PPC. It seems your solaris code is x86_64 exclusively. In a linux section we will need to take care of ppc, ia64 and i386 too. So thing like eax, ebx ecx and edx looks suspicious to me. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/