Re: Xen headers: Update to Xen 3.3 headers

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

On Wed, Aug 20, 2008 at 11:00:19PM +0200, Christoph Egger wrote:
> 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).

There are some path were this would be tricky to get right without a
noticeable performance impact. 
For now I think we should stick to the Xen 3.0 interface for the general
case (I'm not talking about specific features); so you'll have to make sure
that your update don't silently switch to a new interface. There are
some hypercalls numbers which did change while keeping the same macro name;
I did make sure that in our sources the macro names did still point to
the old number; this has to be done for your patch too.


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

then this has to be documented, in the same way I've (just) documented that
Xen 2.0.x is deprecated.

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

Or keep it in our tree if they don't want it.

> 
> >> [...]
> >>     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 ?

Why explain to them ? it's our source tree, we can keep local files or
local patches if we want, isn't it ?

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

I used Xen as vendor tag, and xen-3-0-20060107 as release tag.
But you can use what you want (as long as it makes sense :); cvs doesn't
care.

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