Date: Wed, 6 May 2015 13:58:31 -0500 From: Eric Badger <eric.badger@compellent.com> To: John Baldwin <jhb@freebsd.org>, Ryan Stone <rysto32@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: PCI PF memory decode disable when sizing VF BARs Message-ID: <554A6457.4060702@compellent.com> In-Reply-To: <2106775.8KnH0oLhUZ@ralph.baldwin.cx> References: <cb2ce4e0ff294bcd982c6db87ae64dfb@mspexmb1.Beer.Town> <11092809.7nmbPfKl0V@ralph.baldwin.cx> <CAFMmRNyUiet0O2WXBv1K%2BTF=qtQT7Tdwf4npcCNKZiF4SZVh8w@mail.gmail.com> <2106775.8KnH0oLhUZ@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/06/15 13:33, John Baldwin wrote: > On Wednesday, May 06, 2015 02:24:24 PM Ryan Stone wrote: >> On Wed, May 6, 2015 at 11:45 AM, John Baldwin <jhb@freebsd.org> wrote: >> >>> There are some devices with BARs in non-standard locations. :( If there is >>> a flag to just disable the VF bar decoding, then ideally we should just be >>> doing that and leaving the global decoding flag alone while sizing the VF >>> BAR. >>> >> Disabling SR-IOV BAR decoding in this function is currently redundant, as >> it's already done in pci_iov.c, but I guess to keep the interface sane it >> makes sense to do it here too. Something like this then? > Ah, sorry, I didn't know you did it in the caller already. Perhaps > then something more like your previous patch, but using the test you > added here (PCIR_IS_IOV) instead of your previous check against BAR > values to decide when to frob the command register? > Does the disabling of VF MSE in pci_iov_config actually protect anything else beyond what happens in pci_read_bar? I gave a read through which suggests "no", but I might have missed something. Just thinking that the code would be a bit more hardy if it were done the same way for both VFs and other devices. Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?554A6457.4060702>