Re: Xen/Xentools 3.3 Domain-Unnamed

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Aug 19, 2008 at 01:41:17PM +0200, Christoph Egger wrote:
> This is what I got from XenSource:
> 
> --------------------------------------------------------------------------------------
> You'll need to do errno remapping at the bottom of libxenctrl/libxenguest,
> or within your equivalent of Linux's privcmd kernel driver.
> 
> Either is easy -- even in libxc there's one shared macro or function that
> provides access to the actual hypercall interface, I'm pretty sure.
> --------------------------------------------------------------------------------------

I think the right way to do this would be to use the Xen's E* macros
in the userland code where it's appropriate, and change the interface
to return the hypervisor's errors though a different channel
(as they don't have the same semantic as the errors from the local OS).
But whatever

> 
> I first tried to fix this in the xentools as suggested by XenSource.
> But then I noticed this had an impact to *all* Dom0 privcmd ioctl's,
> which made things worse.
> 
> Reason: Only IOCTL_PRIVCMD_HYPERCALL is a passthrough from
> userspace into the hypervisor and back. All others also perform
> hypercalls into the hypervisor, but the return code from them
> is never passed back into userspace.
> 
> Therefore, the easiest fix (and with minimal effort) is to do
> the error code remapping in sys/arch/xen/xen/privcmd.c after the hypercall
> returned in IOCTL_PRIVCMD_HYPERCALL.
> 
> Attached patch is doing this and works fine.
> With it, there are no longer any phantom domains named
> "Domain-Unnamed" left.

Are EDEADLK/EAGAIN the only error codes that need translation ?

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--