linux-kernel - RE: [PATCH] PCI/IOV: Decrease VF memory BAR size to save host memory occupied by PTEs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <da760d45e4714a289220591a0f2efb97@AcuMS.aculab.com>
Date:   Tue, 11 Oct 2022 11:48:05 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Leon Romanovsky' <leon@...nel.org>, Rui Ma <Rui.Ma@....com>
CC:     "helgaas@...nel.org" <helgaas@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "Alexander.Deucher@....com" <Alexander.Deucher@....com>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>
Subject: RE: [PATCH] PCI/IOV: Decrease VF memory BAR size to save host memory
 occupied by PTEs

From: Leon Romanovsky
> Sent: 11 October 2022 12:37
> 
> On Tue, Oct 11, 2022 at 07:23:25PM +0800, Rui Ma wrote:
> > In some certain SR-IOV scene, when the device physical space(such as Video
> > RAM)is fixed, as the number of VFs increases, some device driver may decrease
> > actual BAR memory space used by each VF. However, the VF BAR memory mapping is
> > always based on the usual BAR probing algorithm in PCIe spec. So do not map this
> > unneeded memory can save host memory which occupied by PTEs. Although each PTE
> > only occupies a few bytes of space on its own, a large number of PTEs can still
> > take up a lot of space.
...
> > +    /*
> > +     * Some SR-IOV device's BAR map range is larger than they can actually use.
> > +     * This extra BAR space occupy too much reverse mapping size(physical page
> > +     * back to the PTEs). So add a divisor shift parameter to resize the request
> > +     * resource of VF according to num of VFs.
> > +     */
> > +	u16 shift = 1;

Why u16??

> > +		virtfn->resource[i].end = virtfn->resource[i].start + (size >> (shift - 1)) - 1;

The 'shift - 1' may require a mask.

...
> > +struct virtfn_get_shift_methods {
> > +	u16 vendor;
> > +	u16 device;
> > +	u16 (*get_shift)(struct pci_dev *dev, u16 arg, int arg2);

More pointless u16 - they just make the code larger.

...
> > +static inline u16 virtfn_get_shift(struct pci_dev *dev, u16 arg1, int arg2)
> > +{
> > +	return (u16)1;
> 
> <...>
> 
> > +	return (u16)1;
> 
> Why do you need these casts? You can omit them.

Kill all the u16

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)