pci_user.c: Cosmetic fixes

Correct leading whitespace for a few lines.

Consistently use more canonical #ifdef to test for COMPAT_FREEBSD32.

Obtained from: CheriBSD
Sponsored by: AFRL, DARPA

pci_user: Rename _old to _freebsd6

The pre-freebsd7 stuff is labeled _old right now. Relabel it as
_freebsd6 instead. No functional change intended. I selected freebsd6
because that's the last versi

pci_user: Rename _old to _freebsd6

The pre-freebsd7 stuff is labeled _old right now. Relabel it as
_freebsd6 instead. No functional change intended. I selected freebsd6
because that's the last version to have the ioctls, although I know
there were changes in the interface for 4, 5 and 6. This broadly batches
what we do with system calls that accumulate changes until we break and
use a new one, we use the last major the system call was in.

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D45867

show more ...

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...

dev/pci: fix potential panic due to bogus VPD data

A panic has been observed on a system with a Intel X520 dual LAN
device. The panic is caused by a KASSERT() noticing that the amount
of VPD data co

dev/pci: fix potential panic due to bogus VPD data

A panic has been observed on a system with a Intel X520 dual LAN
device. The panic is caused by a KASSERT() noticing that the amount
of VPD data copied out to the pciconf command does not match the
amount of data read from the device.

The cause of the size mismatch was VPD data that started with 0x82,
the VPD tag that indicates that a VPD ident follows, but with a length
of more than 255 characters, which happens to be the maximum ident
size supported by the API between kernel and the pciconf program.
The data provided did not resemble an actual VPD identifier, and it
can be assumed that the initial tag value 0x82 happens to be there
by accident.

An ident size of 255 far exceeds the sensible length of that data
element, which is in the order of at most 30 to 40 bytes.

This patch adds several consitstency checks to the VPD parser, the
most critical being that ident lengths of more than 255 bytes are
rejected. Other checks reject VPD with more than one ident tag or
with an empty (zero length) ident string.

This patch prevents the panic that occured when "pciconf -lV" was
executed on the affected system.

During the anaylsis of the issue and the VPD code it has been
found that the VPD parser uses a state machine that accepts tags
in any order and combination. This is a bad match for the actual
VPD data, which has a very simple structure that can be parsed
with a non-recursive direct descent parser (which always knows
exactly which token to expect next).

A review fpr a much simpler VPD parser that performs many more
consistency checks and rejects invalid VPD has been proposed in
review https://reviews.freebsd.org/D34268.

Reported by: mikej at paymentallianceintl.com (Michael Jung)
Approved by: jhb
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D34255

show more ...

Create wrapper for Giant taken for newbus

Create a wrapper for newbus to take giant and for busses to take it too.
bus_topo_lock() should be called before interacting with newbus routines
and unlock

Create wrapper for Giant taken for newbus

Create a wrapper for newbus to take giant and for busses to take it too.
bus_topo_lock() should be called before interacting with newbus routines
and unlocked with bus_topo_unlock(). If you need the topology lock for
some reason, bus_topo_mtx() will provide that.

Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D31831

show more ...

bus: Make BUS_TRANSLATE_RESOURCE behave more like other bus methods

- Return an errno value upon failure, instead of 1.
- Provide a bus_translate_resource() wrapper.
- Implement the generic version,

bus: Make BUS_TRANSLATE_RESOURCE behave more like other bus methods

- Return an errno value upon failure, instead of 1.
- Provide a bus_translate_resource() wrapper.
- Implement the generic version, which traverses the hierarchy until a
bus driver with a non-trivial implementation is found, in subr_bus.c
like other similar default implementations.
- Make ofw_pcib_translate_resource() return an error if a matching PCI
address range is not found.
- Make generic_pcie_translate_resource_common() return an int instead of
a bool. Fix up callers.

No functional change intended.

Reviewed by: imp, jhb
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32855

show more ...

pci: Add an ioctl to perform I/O to BARs

This is useful for bhyve, which otherwise has to use /dev/io to handle
accesses to I/O port BARs when PCI passthrough is in use.

Reviewed by: imp, kib
Discu

pci: Add an ioctl to perform I/O to BARs

This is useful for bhyve, which otherwise has to use /dev/io to handle
accesses to I/O port BARs when PCI passthrough is in use.

Reviewed by: imp, kib
Discussed with: jhb
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31307

show more ...

/dev/pci: clarify meaning of writeable file descriptor

Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D31317

pci_user: fix build for 32-bit platforms

Commit: f2f1ab39c040 ("pci_user: call bus_translate_resource before BAR mmap")
broke build for 32-bit platforms due to rman_res_t and vm_paddr_t
incompatible

pci_user: fix build for 32-bit platforms

Commit: f2f1ab39c040 ("pci_user: call bus_translate_resource before BAR mmap")
broke build for 32-bit platforms due to rman_res_t and vm_paddr_t
incompatible types. Fix that.

show more ...

pci_user: call bus_translate_resource before BAR mmap

On some armv8 machines it is possible that the mapping between CPU
and PCI bus BAR base addresses is not 1:1. In case a BAR is allocated
in kern

pci_user: call bus_translate_resource before BAR mmap

On some armv8 machines it is possible that the mapping between CPU
and PCI bus BAR base addresses is not 1:1. In case a BAR is allocated
in kernel using bus_alloc_resource_any this translation is handled in
ofw_pci_activate_resource.

Do the same in pci_user.c by calling bus_translate_resource devmethod.
This fixes mmaping BARs to userspace on Marvell SoCs (Armada 7k8k/CN913x)
and possibly many other platforms.

Submitted by: Kornel Duleba <mindal@semihalf.com>
Reviewed by: kib
Obtained from: Semihalf
Sponsored by: Marvell
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D29604

show more ...

pci: clean up empty lines in .c and .h files

Remove "All rights reserved" phrase from copyright notes.

With the ratification of the Berne Convention in 2000, it became obsolete.

I have removed that phrase and the "(c)" only from files without

Remove "All rights reserved" phrase from copyright notes.

With the ratification of the Berne Convention in 2000, it became obsolete.

I have removed that phrase and the "(c)" only from files without copyright
claims by other parties. There are 2 files (pci.c, pci_private.h) that are
also claimed by Michael Smith <msmith@freebsd.org> and by BSDi, which have
therefore not been included in this commit.

When all member nations of the Buenos Aires Convention adopted the Berne
Convention, the phrase "All rights reserved" became unnecessary to assert
copyright. Remove it from files under my copyright.

There are 2 files (pci.c, pci_private.h) that) that do also bear msmith's
and BSDi's copyright. I have left them unchanged for now, since I do not
know whether they (or the legal successor in case of BSDi) would agree.

show more ...

Hoist locking giant back up into the ioctl handler

Move the locking back into the ioctl handler. This "fixes" the race where we hve
a hot plug event just after the dropping of Giant in pci_find_dbsf

Hoist locking giant back up into the ioctl handler

Move the locking back into the ioctl handler. This "fixes" the race where we hve
a hot plug event just after the dropping of Giant in pci_find_dbsf, assuming the
driver doesn't then call anything that drops and picks up Giant again... It's a
little safer since don't think it doesn't, but we lack the tools to know for
sure.

show more ...

Push Giant down one layer

The /dev/pci device doesn't need GIANT, per se. However, one routine
that it calls, pci_find_dbsf implicitly does. It walks a list that can
change when PCI scans a new bus.

Push Giant down one layer

The /dev/pci device doesn't need GIANT, per se. However, one routine
that it calls, pci_find_dbsf implicitly does. It walks a list that can
change when PCI scans a new bus. With hotplug, this means we could
have a race with that scanning. To prevent that, take out Giant around
scanning the list.

However, given that we have places in the tree that drop giant, if
held when we call into them, the whole use of Giant to protect newbus
may be less effective that we desire, so add a comment about why we're
talking it out, and we'll address the issue when we lock newbus with
something other than Giant.

show more ...

MFHead @r350386

Sponsored by: The FreeBSD Foundation

Need to apply the PCIM_BAR_MEM_BASE mask to the physical memory
address before returning it to the user. Some of the least significant
bits have special meaning and should be masked away.

Discussed

Need to apply the PCIM_BAR_MEM_BASE mask to the physical memory
address before returning it to the user. Some of the least significant
bits have special meaning and should be masked away.

Discussed with: kib@
MFC after: 3 days
Sponsored by: Mellanox Technologies

show more ...

Merge ^/head r340427 through r340868.

Fix stray tab.

Reported by: jbeich
MFC after: 3 days
MFC with: r340489
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D18011

Fix freebsd32 support for PCIOCGETCONF.

This fixes regresssions in pciconf -l and some ports as reported on
freebsd-current:

https://lists.freebsd.org/pipermail/freebsd-current/2018-November/072144

Fix freebsd32 support for PCIOCGETCONF.

This fixes regresssions in pciconf -l and some ports as reported on
freebsd-current:

https://lists.freebsd.org/pipermail/freebsd-current/2018-November/072144.html

Reported by: jbeich
Reviewed by: kib (also proposed an idential patch)
Tested by: jbeich
MFC after: 3 days
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D18011

show more ...

MFH r338661 through r339200.

Sponsored by: The FreeBSD Foundation

Merge ^/head r338988 through r339014.

Centralize compat support for PCIOCGETCONF.

The pre-7.x compat for both native and 32-bit code was already in
pci_user.c. Use this infrastructure to add implement 32-bit support.
This is more correc

Centralize compat support for PCIOCGETCONF.

The pre-7.x compat for both native and 32-bit code was already in
pci_user.c. Use this infrastructure to add implement 32-bit support.
This is more correct as ioctl(2) commands only have meaning in the
context of a file descriptor.

Reviewed by: kib
Approved by: re (gjb)
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential revision: https://reviews.freebsd.org/D17324

show more ...

Merge ^/head r338392 through r338594.

Don't directly dereference a user pointer in the VPD ioctl.

The PCIOCLISTVPD ioctl on /dev/pci is used to fetch a list of VPD
key-value pairs for a specific PCI function. It is used by
'pciconf -l

Don't directly dereference a user pointer in the VPD ioctl.

The PCIOCLISTVPD ioctl on /dev/pci is used to fetch a list of VPD
key-value pairs for a specific PCI function. It is used by
'pciconf -l -V'. The list is stored in a userland-supplied buffer as
an array of variable-length structures where the key and data length
are stored in a fixed-size header followed by the variable-length
value as a byte array. To facilitate walking this array in userland,
<sys/pciio.h> provides a PVE_NEXT() helper macro to return a pointer
to the next array element by reading the the length out of the current
header and using it to compute the address of the next header.

To simplify the implementation, the ioctl handler was also using
PVE_NEXT() when on the user address of the user buffer to compute the
user address of the next array element. However, the PVE_NEXT() macro
when used with a user address was reading the value's length by
indirecting the user pointer. The value was ready after the current
record had been copied out to the user buffer, so it appeared to work
on architectures where user addresses are directly dereferencable from
the kernel (all but powerpc and i386 after the 4:4 split). The recent
enablement of SMAP on amd64 caught this violation however. To fix,
add a variant of PVE_NEXT() for use in the ioctl handler that takes an
explicit value length.

Reported by: Jeffrey Pieper @ Intel
Reviewed by: kib
Approved by: re (gjb)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D16800

show more ...