Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1545314 > unrolled thread

Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi Stephen Hemminger <stephen@networkplumber.org> - 2016-12-20 18:30 +0100
    Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi Christoph Hellwig <hch@infradead.org> - 2016-12-21 13:20 +0100
      Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi Christoph Hellwig <hch@infradead.org> - 2016-12-21 15:30 +0100
        Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi Paolo Bonzini <pbonzini@redhat.com> - 2016-12-21 16:50 +0100
          Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi Christoph Hellwig <hch@infradead.org> - 2016-12-21 16:50 +0100
            Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi Paolo Bonzini <pbonzini@redhat.com> - 2016-12-21 18:30 +0100
            Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi Christoph Hellwig <hch@infradead.org> - 2016-12-21 19:00 +0100
              Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi Stephen Hemminger <stephen@networkplumber.org> - 2016-12-21 19:10 +0100
                RE: [PATCH 12/15] hyperv: move VMBus connection ids to uapi KY Srinivasan <kys@microsoft.com> - 2016-12-21 21:20 +0100
                  Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi Stephen Hemminger <stephen@networkplumber.org> - 2016-12-29 19:30 +0100
                  Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi Paolo Bonzini <pbonzini@redhat.com> - 2017-01-02 09:30 +0100
                  Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi Stephen Hemminger <stephen@networkplumber.org> - 2017-01-02 20:50 +0100
                    Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi Paolo Bonzini <pbonzini@redhat.com> - 2017-01-03 10:40 +0100
            Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi Paolo Bonzini <pbonzini@redhat.com> - 2016-12-21 19:00 +0100
            Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi Stephen Hemminger <stephen@networkplumber.org> - 2016-12-21 19:00 +0100

#1545314 — Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi

On Tue, 20 Dec 2016 18:55:59 +0300
Roman Kagan <rkagan@virtuozzo.com> wrote:

> Userspace will need them too.
> 
> Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>

What userspace? I am worried about creating more stable API's that can't change.

[toc] | [next] | [standalone]

#1545734

On Wed, Dec 21, 2016 at 09:29:39AM +0300, Roman Kagan wrote:
> QEMU in particular.  We're planning to implement VMBus devices in QEMU
> and would like to have the definitions shared with the Linux guest
> drivers for Hyper-V.

And that's everything but a userspace API.  The way to go for protocol
constants is to have a normal kernel header that is not exported, and
a copy of it wherever else you need it.

[toc] | [prev] | [next] | [standalone]

#1545781

On Wed, Dec 21, 2016 at 03:59:20PM +0300, Roman Kagan wrote:
> That's fine by me.
> 
> I guess the series should then start with a complete move
> arch/x86/include/uapi/asm/hyperv.h ->
> arch/x86/include/asm/hyperv_proto.h, and the remaining patches have to
> change the latter instead of the former?

That would be my preference, but we'll need to figure out why
hyperv has ever been a UABI header, and if anyone is using it.

[toc] | [prev] | [next] | [standalone]

#1545841

On 21/12/2016 15:26, Christoph Hellwig wrote:
> On Wed, Dec 21, 2016 at 03:59:20PM +0300, Roman Kagan wrote:
>> That's fine by me.
>>
>> I guess the series should then start with a complete move
>> arch/x86/include/uapi/asm/hyperv.h ->
>> arch/x86/include/asm/hyperv_proto.h, and the remaining patches have to
>> change the latter instead of the former?
> 
> That would be my preference, but we'll need to figure out why
> hyperv has ever been a UABI header, and if anyone is using it.

QEMU uses it, but we already bundle the header files and update them
periodically from the files that Linux installs.  So any change in Linux
would not break the QEMU build; having the header in UAPI is convenient
but I guess our update scripts could do whatever Linux's
scripts/headers_install.sh does.

That said, there are precedents in using UAPI this way for PV
interfaces.  See for example include/uapi/linux/virtio*.h and
arch/x86/include/uapi/asm/kvm_para.h.

Paolo

[toc] | [prev] | [next] | [standalone]

#1545842

On Wed, Dec 21, 2016 at 04:39:18PM +0100, Paolo Bonzini wrote:
> That said, there are precedents in using UAPI this way for PV
> interfaces.  See for example include/uapi/linux/virtio*.h and
> arch/x86/include/uapi/asm/kvm_para.h.

We have all kinds of historical examples, but most of them turned
into a major pain sooner or later - my favourite example are the
SCSI protocol headers.

Protocols needs to stay compatible on the (virtual) wire, but not
on the language level.  Locking us into the strict UABI policies
for them just make someone life horrible further down the road.

[toc] | [prev] | [next] | [standalone]

#1545907

On 21/12/2016 16:43, Christoph Hellwig wrote:
> On Wed, Dec 21, 2016 at 04:39:18PM +0100, Paolo Bonzini wrote:
>> That said, there are precedents in using UAPI this way for PV
>> interfaces.  See for example include/uapi/linux/virtio*.h and
>> arch/x86/include/uapi/asm/kvm_para.h.
> 
> We have all kinds of historical examples, but most of them turned
> into a major pain sooner or later - my favourite example are the
> SCSI protocol headers.

Mine too, and because of how uapi/ was created there are quite a few
such historical headers (my favourite is cuda.h, just because of the name).

> Protocols needs to stay compatible on the (virtual) wire, but not
> on the language level.  Locking us into the strict UABI policies
> for them just make someone life horrible further down the road.

The ABI for this kind of thing is not changing much anyway, because it's
the hardware or processor or (as in this case) hypervisor ABI.

The more interesting question is about the API, and here in the end it
seems to be up to the maintainer.

Some have explicitly asked to move stuff *out* of UAPI, for example the
x86 guys have removed msr-index.h from UAPI recently.  Others are okay
with it and they simply aren't strict on cleanups that might break the
*programming* interface, as in patch 15 of this series.  See for example
pci_regs.h commit 846fc70986a6, "PCI/AER: Rename PCI_ERR_UNC_TRAIN to
PCI_ERR_UNC_UND", everybody just moved on and QEMU adjusted its use of
PCI_ERR_UNC_TRAIN.

Having this in UAPI has been convenient for QEMU, but of course the
kernel couldn't care less.  So if KY prefers to have the header outside
UAPI, we will just follow suit...

Paolo

[toc] | [prev] | [next] | [standalone]

#1545912

On Wed, Dec 21, 2016 at 09:50:49AM -0800, Stephen Hemminger wrote:
> Lastly, there is licensing issues on headers. It would be good to have any
> userspace ABI headers licensed with a more liberal license so that BSD and DPDK drivers
> could use them directly. Right now each one reinvents.

Microsoft could easily solves this problem by offering a suitably
liberally licensed header documenting the full HyperV guest protocol
that Linux and other projects could use.

[toc] | [prev] | [next] | [standalone]

#1545920

On Wed, 21 Dec 2016 09:58:36 -0800
Christoph Hellwig <hch@infradead.org> wrote:

> On Wed, Dec 21, 2016 at 09:50:49AM -0800, Stephen Hemminger wrote:
> > Lastly, there is licensing issues on headers. It would be good to have any
> > userspace ABI headers licensed with a more liberal license so that BSD and DPDK drivers
> > could use them directly. Right now each one reinvents.  
> 
> Microsoft could easily solves this problem by offering a suitably
> liberally licensed header documenting the full HyperV guest protocol
> that Linux and other projects could use.

The issue is if same header file mixes kernel and userspace API stuff.

Once the files are arranged right, I will submit trivial change to comments
to indicate the liberal licensing of userspace API headers.

[toc] | [prev] | [next] | [standalone]

#1545983

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Wednesday, December 21, 2016 10:03 AM
> To: Christoph Hellwig <hch@infradead.org>
> Cc: Paolo Bonzini <pbonzini@redhat.com>; Roman Kagan
> <rkagan@virtuozzo.com>; Radim Krčmář <rkrcmar@redhat.com>; KY
> Srinivasan <kys@microsoft.com>; Vitaly Kuznetsov
> <vkuznets@redhat.com>; kvm@vger.kernel.org; Denis V . Lunev
> <den@openvz.org>; Haiyang Zhang <haiyangz@microsoft.com>;
> x86@kernel.org; linux-kernel@vger.kernel.org; Ingo Molnar
> <mingo@redhat.com>; H. Peter Anvin <hpa@zytor.com>;
> devel@linuxdriverproject.org; Thomas Gleixner <tglx@linutronix.de>
> Subject: Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi
> 
> On Wed, 21 Dec 2016 09:58:36 -0800
> Christoph Hellwig <hch@infradead.org> wrote:
> 
> > On Wed, Dec 21, 2016 at 09:50:49AM -0800, Stephen Hemminger wrote:
> > > Lastly, there is licensing issues on headers. It would be good to have any
> > > userspace ABI headers licensed with a more liberal license so that BSD
> and DPDK drivers
> > > could use them directly. Right now each one reinvents.
> >
> > Microsoft could easily solves this problem by offering a suitably
> > liberally licensed header documenting the full HyperV guest protocol
> > that Linux and other projects could use.
> 
> The issue is if same header file mixes kernel and userspace API stuff.
> 
> Once the files are arranged right, I will submit trivial change to comments
> to indicate the liberal licensing of userspace API headers.

Let us take this one step at a time. I know for a fact that not all the guest host
protocols on Hyper-V are guaranteed to be stable. Some of the protocols are part of
the published MSFT standards such RNDIS and these obviously are guaranteed to be
stable. For the rest it is less clear. The fact that we need to ensure compatibility of existing
Windows guests tells me that any host side changes will be versioned and the hosts will always
support older guests.

I would like to minimize what we include in the uapi header; especially when MSFT has made no guarantees
with regards how  they may be evolved. I will also work on getting some clarity on both stability and
under what license we would expose the uapi header.

Regards,

K. Y

[toc] | [prev] | [next] | [standalone]

#1548339

On Wed, 28 Dec 2016 20:09:44 +0300
Roman Kagan <rkagan@virtuozzo.com> wrote:

> On Wed, Dec 21, 2016 at 07:54:11PM +0000, KY Srinivasan wrote:
> > 
> >   
> > > -----Original Message-----
> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Wednesday, December 21, 2016 10:03 AM
> > > To: Christoph Hellwig <hch@infradead.org>
> > > Cc: Paolo Bonzini <pbonzini@redhat.com>; Roman Kagan
> > > <rkagan@virtuozzo.com>; Radim Krčmář <rkrcmar@redhat.com>; KY
> > > Srinivasan <kys@microsoft.com>; Vitaly Kuznetsov
> > > <vkuznets@redhat.com>; kvm@vger.kernel.org; Denis V . Lunev
> > > <den@openvz.org>; Haiyang Zhang <haiyangz@microsoft.com>;
> > > x86@kernel.org; linux-kernel@vger.kernel.org; Ingo Molnar
> > > <mingo@redhat.com>; H. Peter Anvin <hpa@zytor.com>;
> > > devel@linuxdriverproject.org; Thomas Gleixner <tglx@linutronix.de>
> > > Subject: Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi
> > > 
> > > On Wed, 21 Dec 2016 09:58:36 -0800
> > > Christoph Hellwig <hch@infradead.org> wrote:
> > >   
> > > > On Wed, Dec 21, 2016 at 09:50:49AM -0800, Stephen Hemminger wrote:  
> > > > > Lastly, there is licensing issues on headers. It would be good to have any
> > > > > userspace ABI headers licensed with a more liberal license so that BSD  
> > > and DPDK drivers  
> > > > > could use them directly. Right now each one reinvents.  
> > > >
> > > > Microsoft could easily solves this problem by offering a suitably
> > > > liberally licensed header documenting the full HyperV guest protocol
> > > > that Linux and other projects could use.  
> > > 
> > > The issue is if same header file mixes kernel and userspace API stuff.
> > > 
> > > Once the files are arranged right, I will submit trivial change to comments
> > > to indicate the liberal licensing of userspace API headers.  
> > 
> > Let us take this one step at a time. I know for a fact that not all the guest host
> > protocols on Hyper-V are guaranteed to be stable. Some of the protocols are part of
> > the published MSFT standards such RNDIS and these obviously are guaranteed to be
> > stable. For the rest it is less clear. The fact that we need to ensure compatibility of existing
> > Windows guests tells me that any host side changes will be versioned and the hosts will always
> > support older guests.
> > 
> > I would like to minimize what we include in the uapi header; especially when MSFT has made no guarantees
> > with regards how  they may be evolved. I will also work on getting some clarity on both stability and
> > under what license we would expose the uapi header.  
> 
> Am I correct assuming that QEMU is currently the only user of
> arch/x86/include/uapi/asm/hyperv.h?
> 
> Then I think we're fine withdrawing it from uapi as a whole and letting
> QEMU pull it in through its header-harvesting scripts (as does now
> anyway).  This would lift all licensing and longterm API stability
> expectations.

That makes sense, but if it is not in uapi then any changes may break QEMU
in future (without regret).

If QEMU is diving in and extracting non UAPI headers then that is a bad idea.
It is outside the scope of this.

[toc] | [prev] | [next] | [standalone]

#1549018

On 28/12/2016 18:09, Roman Kagan wrote:
> Am I correct assuming that QEMU is currently the only user of
> arch/x86/include/uapi/asm/hyperv.h?
> 
> Then I think we're fine withdrawing it from uapi as a whole and letting
> QEMU pull it in through its header-harvesting scripts (as does now
> anyway).  This would lift all licensing and longterm API stability
> expectations.

Actually, QEMU's header-harvesting scripts use uapi/ headers
exclusively, since they are built on "make headers_install".

The extra cleanups that QEMU does on top are to allow compilation of the
headers on non-Linux machines.  They don't really do much more than
changing Linux (linux/types.h) integer types to the C99 (stdint.h)
equivalents.

Paolo

[toc] | [prev] | [next] | [standalone]

#1549376

On Wed, 28 Dec 2016 20:09:44 +0300
Roman Kagan <rkagan@virtuozzo.com> wrote:

> On Wed, Dec 21, 2016 at 07:54:11PM +0000, KY Srinivasan wrote:
> > 
> >   
> > > -----Original Message-----
> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Wednesday, December 21, 2016 10:03 AM
> > > To: Christoph Hellwig <hch@infradead.org>
> > > Cc: Paolo Bonzini <pbonzini@redhat.com>; Roman Kagan
> > > <rkagan@virtuozzo.com>; Radim Krčmář <rkrcmar@redhat.com>; KY
> > > Srinivasan <kys@microsoft.com>; Vitaly Kuznetsov
> > > <vkuznets@redhat.com>; kvm@vger.kernel.org; Denis V . Lunev
> > > <den@openvz.org>; Haiyang Zhang <haiyangz@microsoft.com>;
> > > x86@kernel.org; linux-kernel@vger.kernel.org; Ingo Molnar
> > > <mingo@redhat.com>; H. Peter Anvin <hpa@zytor.com>;
> > > devel@linuxdriverproject.org; Thomas Gleixner <tglx@linutronix.de>
> > > Subject: Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi
> > > 
> > > On Wed, 21 Dec 2016 09:58:36 -0800
> > > Christoph Hellwig <hch@infradead.org> wrote:
> > >   
> > > > On Wed, Dec 21, 2016 at 09:50:49AM -0800, Stephen Hemminger wrote:  
> > > > > Lastly, there is licensing issues on headers. It would be good to have any
> > > > > userspace ABI headers licensed with a more liberal license so that BSD  
> > > and DPDK drivers  
> > > > > could use them directly. Right now each one reinvents.  
> > > >
> > > > Microsoft could easily solves this problem by offering a suitably
> > > > liberally licensed header documenting the full HyperV guest protocol
> > > > that Linux and other projects could use.  
> > > 
> > > The issue is if same header file mixes kernel and userspace API stuff.
> > > 
> > > Once the files are arranged right, I will submit trivial change to comments
> > > to indicate the liberal licensing of userspace API headers.  
> > 
> > Let us take this one step at a time. I know for a fact that not all the guest host
> > protocols on Hyper-V are guaranteed to be stable. Some of the protocols are part of
> > the published MSFT standards such RNDIS and these obviously are guaranteed to be
> > stable. For the rest it is less clear. The fact that we need to ensure compatibility of existing
> > Windows guests tells me that any host side changes will be versioned and the hosts will always
> > support older guests.
> > 
> > I would like to minimize what we include in the uapi header; especially when MSFT has made no guarantees
> > with regards how  they may be evolved. I will also work on getting some clarity on both stability and
> > under what license we would expose the uapi header.  
> 
> Am I correct assuming that QEMU is currently the only user of
> arch/x86/include/uapi/asm/hyperv.h?
> 
> Then I think we're fine withdrawing it from uapi as a whole and letting
> QEMU pull it in through its header-harvesting scripts (as does now
> anyway).  This would lift all licensing and longterm API stability
> expectations.
> 
> Roman.

Thanks, that prevents lots of problems.
That is how I handle iproute2 as well.

[toc] | [prev] | [next] | [standalone]

#1549646

On 02/01/2017 20:39, Stephen Hemminger wrote:
>>>
>>> I would like to minimize what we include in the uapi header; especially when MSFT has made no guarantees
>>> with regards how  they may be evolved. I will also work on getting some clarity on both stability and
>>> under what license we would expose the uapi header.  
>> Am I correct assuming that QEMU is currently the only user of
>> arch/x86/include/uapi/asm/hyperv.h?
>>
>> Then I think we're fine withdrawing it from uapi as a whole and letting
>> QEMU pull it in through its header-harvesting scripts (as does now
>> anyway).  This would lift all licensing and longterm API stability
>> expectations.
>
> Thanks, that prevents lots of problems.
> That is how I handle iproute2 as well.

Except it wouldn't work.  But no big deal, I guess we'll just
synchronize hyperv.h manually. :((

Paolo

[toc] | [prev] | [next] | [standalone]

#1545913

On 21/12/2016 18:50, Stephen Hemminger wrote:
> The other problem with the hyperv headers is they were initially done with
> only the Linux driver usage in mind. This made perfect sense at the time,
> the problem is that they mix internal state with protocol definitions.

Yes, and this was partly fixed when KVM started to use some of those
definitions too (the implementation of Hyper-V protocols is split
between kernel and userspace).

> Lastly, there is licensing issues on headers. It would be good to have any
> userspace ABI headers licensed with a more liberal license so that BSD and DPDK drivers
> could use them directly. Right now each one reinvents.

Other projects are using sanitized userspace ABI headers just fine, so
this is something that lawyers should sort out before kernel hackers do.

Paolo

[toc] | [prev] | [next] | [standalone]

#1545917

On Wed, 21 Dec 2016 07:43:48 -0800
Christoph Hellwig <hch@infradead.org> wrote:

> On Wed, Dec 21, 2016 at 04:39:18PM +0100, Paolo Bonzini wrote:
> > That said, there are precedents in using UAPI this way for PV
> > interfaces.  See for example include/uapi/linux/virtio*.h and
> > arch/x86/include/uapi/asm/kvm_para.h.  
> 
> We have all kinds of historical examples, but most of them turned
> into a major pain sooner or later - my favourite example are the
> SCSI protocol headers.
> 
> Protocols needs to stay compatible on the (virtual) wire, but not
> on the language level.  Locking us into the strict UABI policies
> for them just make someone life horrible further down the road.

If the the protocols come from external sources (like the current NDIS definitions),
then it is not a big deal. There is some overlap already where NDIS is used multiple
places and there are multiple header files with same definition. That could be
fixed.

The bigger problem is that some of the API's between guest and host could be
implemented multiple ways and don't want userspace ABI files constraining how
something like atomic bit operation for wakeup is done.

The other problem with the hyperv headers is they were initially done with
only the Linux driver usage in mind. This made perfect sense at the time,
the problem is that they mix internal state with protocol definitions.

Lastly, there is licensing issues on headers. It would be good to have any
userspace ABI headers licensed with a more liberal license so that BSD and DPDK drivers
could use them directly. Right now each one reinvents.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web