Re: Xen/Xentools 3.3 Domain-Unnamed

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

On Tue, Aug 19, 2008 at 02:00:22PM +0200, Christoph Egger wrote:
> On Tuesday 19 August 2008 13:47:46 Manuel Bouyer wrote:
> > 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
> 
> That is a lot of work. First, you have to prefix Xen's E* macros and change
> all C code to use them in order to not interfer with <sys/errno.h>.

Yes

> 
> Second, you have to maintain a copy as a python module since
> python's  errno  is used.

I don't think so. The point is to change the API, as python's errno
errno is from the OS, not from the hypervisor. The hypervisor's
errno would be passed as a parameter of the hypercall, just like other
parameters.

> 
> Third, this is almost the opposite what XenSource said and therefore
> I don't believe in accepting those patches (and I'm not going to maintain
> patches in pkgsrc I don't get upstream).
> 
> So this is not the way to go. Sorry.

This is how I understood it.

> 
> > > 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 ?
> 
> I can think of EWOULDBLOCK but this is an alias to EAGAIN. So yes,
> nothing else has bitten us so far.

Not yet. I'd rather take the whole macro list and see what the differences
are.

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