Re: Xen headers: Update to Xen 3.3 headers

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

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 ?

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.



> 
> 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.

> 
> 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/

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.

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