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(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/