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

Looking into pkgsrc, w/o the Xen2 packages Xen 3.1. are the oldest ones.
Why don't we have Xen 3.1 hypercalls implicitely with the deprecation of
Xen 2 ?

BTW: Which format is this src/distrib/notes/common/main using?
How do I view the content?

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

Sure, I just wanted to make the required effort for updating the headers
as small as possible - in particular the merging part.

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

Ok, fine.


Christoph