Re: Xen headers: Update to Xen 3.3 headers

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

Manuel Bouyer wrote:
> On Wed, Aug 20, 2008 at 05:42:58PM +0200, Christoph Egger wrote:
> > Hi,
> >
> > Attached patch updates the Xen3 public headers to the ones provided by
> > Xen 3.3.
>
> What does it bring us, exactly ? AFAIK the interface is
> backward-compatible, are there any features we want to use that are not in
> Xen 3.1.x ?

Yes. For example, machine check support and ACPI S3 host.
I already have patches for this.

> Also, you'll have to make sure NetBSD is still using the Xen 3.0 hypercalls
> where appropriate (for now we're always using the Xen 3.0 hypercalls,
> even on newer hypervisors); we don't want to loose compatibility with
> older hypervisors.

There are two ways to detect if a hypercall is available or not:

1. Query for the Xen version and disable a whole feature as once at boot 
time.

2. If a new hypercall is used on an old hypervisor, it fails with
-ENOSYS (Xen error code).

I'm fine with keeping backward-compatible to Xen 3.0 till opening netbsd-5.

After netbsd-5 I would like to have Xen 3.1 hypercalls as requirement.


> > Three main things to mention:
> >
> > 1.  In io/ring.h  the Linux specific macros mb(), rmb() and wmb() have been
> >      replaced with xen_mb(), xen_rmb() and xen_wmb().
> >      I added code which makes these an alias to x86_mfence(), x86_lfence()
> >      and x86_sfence().
> >
> > 2. In io/xs_wire.h  NetBSD used "volatile" for the ring descriptors.
> >      I tried to bring this change upstream to reduce the diff but got
> >      rejected with:
> >
> > ----------------------------------
> > We don't use volatile. If extra ordering constraints are required then the
> > access code should be amended to include extra barriers.
> > -----------------------------------
>
> I don't think will make the same thing. Specifically, I don't think barrier
> will prevent the compiler from caching a memory value in a register;
> this is what volatile is for. Unless I missed a compiler directive which
> would do that, we need to keep the volatile here.

Ok, I will try again getting this upstream.

> > 3. In io/blkif.h  NetBSD added some structures  blkif_x86_32_request/response
> >      and blkif_x86_64_request/response.
> >      I tried to bring this change upstream to reduce the diff but got
> >      rejected:
> >
> > --------------------------------------------------------------------------------------
> > XenSource:
> > Just do the same as we do in Linux and put these defs in your NetBSD private
> > header space.
> >
> > Me:
> > That sounds like "All OS's have to go the Linux way" (which also includes
> > Xen's Minios (stubdom))  instead of "fix it once and for all".
> >
> > XenSource:
> > Quite the opposite. By doing it in your own header files you can specify the
> > structure names and so on exactly how you would like them to be for the
> > particular OS concerned.
> >
> > Me:
> > I'm concerned about having/keeping the API/ABI the same between all OS's and
> > not about their implementation.
> >
> > XenSource:
> > The interfaces (both the API exposed by public/ headers; and the ABI they
> > describe) won't change. At least not in a way that isn't backward
> > compatible. Or we'd be breaking old OSes all the time!
> > We might add: why would placing those extra struct definitions in the public
> > headers make it any more or less likely that we'll break compatibility in
> > future? That makes no sense to us.
> > --------------------------------------------------------------------------------------
> >
> >      Therefore, the attached patch as a standalone breaks the build of the
> >      xbd backend driver. There's a need for a second patch which re-adds the
> >      missing structures in a NetBSD/Xen MD header similar to what is Linux
> >      doing to keep things building.
>
> I don't like it; if we go this route it should be inclued from one of the
> existing MD header in xen3-public/

How should I explain that XenSource ?

> Also, please don't commit it as a patch: import the unmodified Xen files
> in the vendor branch, and use cvs to do the merge (that is, do the import
> in the cvs way). I did import the xen 3.1.x headers in the vendor branch.
> It was not done for the 3.2.x headers, and was a mistake.

That will be my first 'import' that way. I hope, I will get it right.
What should I use as vendor and release tags ?

Christoph