Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 3 Feb 2021 14:09:06 +0000
From:   Wei Liu <wei.liu@kernel.org>
To:     Arnd Bergmann <arnd@kernel.org>
Cc:     Wei Liu <wei.liu@kernel.org>,
        Michael Kelley <mikelley@microsoft.com>,
        Linux on Hyper-V List <linux-hyperv@vger.kernel.org>,
        "virtualization@lists.linux-foundation.org" 
        <virtualization@lists.linux-foundation.org>,
        Linux Kernel List <linux-kernel@vger.kernel.org>,
        Vineeth Pillai <viremana@linux.microsoft.com>,
        Sunil Muthuswamy <sunilmut@microsoft.com>,
        Nuno Das Neves <nunodasneves@linux.microsoft.com>,
        "pasha.tatashin@soleen.com" <pasha.tatashin@soleen.com>,
        KY Srinivasan <kys@microsoft.com>,
        Haiyang Zhang <haiyangz@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        Arnd Bergmann <arnd@arndb.de>,
        "open list:GENERIC INCLUDE/ASM HEADER FILES" 
        <linux-arch@vger.kernel.org>
Subject: Re: [PATCH v5 13/16] asm-generic/hyperv: introduce hv_device_id and
 auxiliary structures
Message-ID: <20210203140906.g35zr7366hh7p5f3@liuwe-devbox-debian-v2>
References: <20210120120058.29138-1-wei.liu@kernel.org>
 <20210120120058.29138-14-wei.liu@kernel.org>
 <MWHPR21MB1593959647DA60219E19C25ED7BC9@MWHPR21MB1593.namprd21.prod.outlook.com>
 <20210202170248.4hds554cyxpuayqc@liuwe-devbox-debian-v2>
 <20210203132601.ftpwgs57qtok47cg@liuwe-devbox-debian-v2>
 <CAK8P3a0m8jEij-RdP1PTcNcJW2+mXQ1dA4=s+JLXhnv+NyFiHw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAK8P3a0m8jEij-RdP1PTcNcJW2+mXQ1dA4=s+JLXhnv+NyFiHw@mail.gmail.com>
User-Agent: NeoMutt/20180716
Precedence: bulk

On Wed, Feb 03, 2021 at 02:49:53PM +0100, Arnd Bergmann wrote:
> On Wed, Feb 3, 2021 at 2:26 PM Wei Liu <wei.liu@kernel.org> wrote:
> > On Tue, Feb 02, 2021 at 05:02:48PM +0000, Wei Liu wrote:
> > > On Tue, Jan 26, 2021 at 01:26:52AM +0000, Michael Kelley wrote:
> > > > From: Wei Liu <wei.liu@kernel.org> Sent: Wednesday, January 20, 2021 4:01 AM
> > > > > +union hv_device_id {
> > > > > + u64 as_uint64;
> > > > > +
> > > > > + struct {
> > > > > +         u64 :62;
> > > > > +         u64 device_type:2;
> > > > > + };
> > > >
> > > > Are the above 4 lines extraneous junk?
> > > > If not, a comment would be helpful.  And we
> > > > would normally label the 62 bit field as
> > > > "reserved0" or something similar.
> > > >
> > >
> > > No. It is not junk. I got this from a header in tree.
> > >
> > > I am inclined to just drop this hunk. If that breaks things, I will use
> > > "reserved0".
> > >
> >
> > It turns out adding reserved0 is required. Dropping this hunk does not
> > work.
> 
> Generally speaking, bitfields are not great for specifying binary interfaces,
> as the actual bit order can differ by architecture. The normal way we get
> around it in the kernel is to use basic integer types and define macros
> for bit masks. Ideally, each such field should also be marked with a
> particular endianess as __le64 or __be64, in case this is ever used with
> an Arm guest running a big-endian kernel.

Thanks for the information.

I think we will need to wait until Microsoft Hypervisor clearly defines
the endianess in its header(s) before we can make changes to the copy in
Linux.

> 
> That said, if you do not care about the specific order of the bits, having
> anonymous bitfields for the reserved members is fine, I don't see a
> reason to name it as reserved.

Michael, let me know what you think. I'm not too fussed either way.

Wei.

> 
>       Arnd