[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 2 Feb 2021 17:02:48 +0000
From: Wei Liu <wei.liu@...nel.org>
To: Michael Kelley <mikelley@...rosoft.com>
Cc: Wei Liu <wei.liu@...nel.org>,
Linux on Hyper-V List <linux-hyperv@...r.kernel.org>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
Linux Kernel List <linux-kernel@...r.kernel.org>,
Vineeth Pillai <viremana@...ux.microsoft.com>,
Sunil Muthuswamy <sunilmut@...rosoft.com>,
Nuno Das Neves <nunodasneves@...ux.microsoft.com>,
"pasha.tatashin@...een.com" <pasha.tatashin@...een.com>,
KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
Arnd Bergmann <arnd@...db.de>,
"open list:GENERIC INCLUDE/ASM HEADER FILES"
<linux-arch@...r.kernel.org>
Subject: Re: [PATCH v5 13/16] asm-generic/hyperv: introduce hv_device_id and
auxiliary structures
On Tue, Jan 26, 2021 at 01:26:52AM +0000, Michael Kelley wrote:
> From: Wei Liu <wei.liu@...nel.org> Sent: Wednesday, January 20, 2021 4:01 AM
> >
> > We will need to identify the device we want Microsoft Hypervisor to
> > manipulate. Introduce the data structures for that purpose.
> >
> > They will be used in a later patch.
> >
> > Signed-off-by: Sunil Muthuswamy <sunilmut@...rosoft.com>
> > Co-Developed-by: Sunil Muthuswamy <sunilmut@...rosoft.com>
> > Signed-off-by: Wei Liu <wei.liu@...nel.org>
> > ---
> > include/asm-generic/hyperv-tlfs.h | 79 +++++++++++++++++++++++++++++++
> > 1 file changed, 79 insertions(+)
> >
> > diff --git a/include/asm-generic/hyperv-tlfs.h b/include/asm-generic/hyperv-tlfs.h
> > index 8423bf53c237..42ff1326c6bd 100644
> > --- a/include/asm-generic/hyperv-tlfs.h
> > +++ b/include/asm-generic/hyperv-tlfs.h
> > @@ -623,4 +623,83 @@ struct hv_set_vp_registers_input {
> > } element[];
> > } __packed;
> >
> > +enum hv_device_type {
> > + HV_DEVICE_TYPE_LOGICAL = 0,
> > + HV_DEVICE_TYPE_PCI = 1,
> > + HV_DEVICE_TYPE_IOAPIC = 2,
> > + HV_DEVICE_TYPE_ACPI = 3,
> > +};
> > +
> > +typedef u16 hv_pci_rid;
> > +typedef u16 hv_pci_segment;
> > +typedef u64 hv_logical_device_id;
> > +union hv_pci_bdf {
> > + u16 as_uint16;
> > +
> > + struct {
> > + u8 function:3;
> > + u8 device:5;
> > + u8 bus;
> > + };
> > +} __packed;
> > +
> > +union hv_pci_bus_range {
> > + u16 as_uint16;
> > +
> > + struct {
> > + u8 subordinate_bus;
> > + u8 secondary_bus;
> > + };
> > +} __packed;
> > +
> > +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".
Wei.
Powered by blists - more mailing lists