CVS log for src/sys/dev/virtio/viocon.c

Up to [cvs.NetBSD.org] / src / sys / dev / virtio

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

Pull up following revision(s) (requested by rin in ticket #914):

	sys/dev/pci/virtio_pci.c: revision 1.50
	sys/dev/pci/virtio_pci.c: revision 1.51
	sys/dev/pci/virtio_pci.c: revision 1.52
	sys/dev/pci/virtio_pci.c: revision 1.53
	sys/dev/pci/virtio_pci.c: revision 1.54
	sys/dev/pci/vioscsi.c: revision 1.35
	sys/dev/pci/ld_virtio.c: revision 1.33
	sys/dev/pci/ld_virtio.c: revision 1.34
	sys/dev/virtio/viocon.c: revision 1.9
	sys/dev/pci/ld_virtio.c: revision 1.35
	sys/dev/pci/virtio.c: revision 1.80
	sys/dev/pci/virtio.c: revision 1.81
	sys/dev/pci/virtio.c: revision 1.82
	sys/dev/pci/virtio_pci.c: revision 1.45
	sys/dev/pci/virtio_pci.c: revision 1.46
	sys/dev/pci/virtio_pci.c: revision 1.47
	sys/dev/pci/virtio_pci.c: revision 1.48
	sys/dev/pci/virtio_pci.c: revision 1.49
	sys/dev/pci/virtio.c: revision 1.79

A single SCSI request may require multiple slots in the virtio queue
but the queue isn't sized for the theoretical maximum. So just use
XS_BUSY to pace the scsipi layer.

viocon(4): Show error in assertion failure.

virtio_read_device_config_le_[24]: Fix for {aarch64,arm}eb
Stop byte-swapping for big-endian aarch64 and arm to fix
corrupted read for, e.g., sc_taglen for vio9p(4).

As described as comments in virtio_pci.c, big-endian aarch64 and
armv7 (armeb) are somewhat special. At the moment, all supported
virtual/real machines are configured as little-endian, and only
CPU cores are switched to big-endian mode during early boot stage.

Most peripheral buses for armeb are LSB as a result, and their
default bus_space(9) functions swap byte-order. Therefore, PIOed
data from memory-mapped devices, as well as pci(4) ones, are
actually LSB, but observed as MSB for armeb.

Therefore, we should not swap byte-order further in
virtio_read_device_config_le_[24] on armeb.

See virtio_pci.c and sys/dev/fdt/virtio_mmio_fdt.c also.
fix spelling mistakes, mainly in comments and log messages.

Split KASSERT(A && B) into KASSERT(A); KASSERT(B).

Fix typo in error message.

Modify a confused expression in ld_virtio_attach().

VIRTIO_BLK_MIN_SEGMENTS should be the total number of non-data segments,
so I rename it to VIRTIO_BLK_CTRL_SEGMENTS.
PR kern/57981.

ld@virtio(4): Fix maximum size parameters.
- SEG_MAX is the maximum number of segments.
- SIZE_MAX is the maximum number of bytes in a single segment.
The maximum transfer size is, therefore, SEG_MAX * SIZE_MAX.
=> Don't add two extra segments in the dmamap vr_payload for the
   header and status -- we already have a separate dmamap vr_cmdsts
   for that.
=> Don't recalculate payload dmamap parameters based on division by
   NBPG, just use the ones specified by the host.
=> Allow SIZE_MAX below MAXPHYS as long as SIZE_MAX*SEG_MAX >=
   MAXPHYS.
Even though ldattach clamps ld->sc_maxxfer to MAXPHYS, make sure to
clamp it in ld_virtio_attach before ld_virtio_alloc_reqs since it
determines the dmamap sizes and bounce buffer allocation and there's
no sense in allocating those larger than ld will use anyway.
PR kern/58338

virtio_pci.c: Nix trailing whitespace.

virtio@pci: Unmap the BARs we actually mapped on >=1.0 detach.
PR kern/58335

virtio@pci: Nix useless sc_mapped_iosize.
This appears to have been a mistaken attempt to pass the subregion
length through to bus_space_unmap, which doesn't make any sense --
bus_space_subregion does not allocate anything and the resulting
handle must not be passed to bus_space_unmap.

Once we pass the size that was actually returned by pci_mapreg_map to
bus_space_unmap, which matches the size passed internally by
pci_mapreg_map to bus_space_map, sc_mapped_iosize is no longer used
and can be flushed.
Prompted by PR kern/58335.

virtio@pci: Don't detach on shutdown.
The virtio bus does not keep state in memory that needs to flushed to
persistent storage.  Typically DVF_DETACH_SHUTDOWN is only needed by,
e.g., disk drivers to flush disk caches (although really, vfs sync
should do that anyway, so maybe we should just nix the option
altogether).
Prompted by PR kern/58335.

virtio@pci: Zero sc_bars_iosize[i] on unmap.
No functional change intended, but this makes the code less brittle.
Prompted by PR kern/58335.

virtio_pci.c: Sort includes.
No functional change intended.

virtio_pci.c: Omit needless blank lines and commented code.
No functional change intended.

virtio_pci.c: Sprinkle KNF.
- No parameter names in function prototypes.
- Fix indentation.
- Break overlong lines.
- Blank line between declarations and rest of block.
virtio_pci.c: Sprinkle const.
No functional change intended.

virtio_pci.c: Use container_of, not cast.
virtio(4): Assert child attach finished before we allow queueing.
Should help catch mistakes like:
PR kern/58555: Kernel panic during boot when using viocon with PCIe

Pull up following revision(s) (requested by riastradh in ticket #778):

	sys/dev/virtio/viocon.c: revision 1.10

viocon(4): Defer viocon_rx_fill til after virtio_child_attach_finish.

Since virtio.c 1.66, virtqueue_enqueue* can't be used until after
virtio_child_attach_finish completes.

https://mail-index.netbsd.org/source-changes/2023/03/23/msg143799.html

PR kern/58555: Kernel panic during boot when using viocon with PCIe

viocon(4): Defer viocon_rx_fill til after virtio_child_attach_finish.

Since virtio.c 1.66, virtqueue_enqueue* can't be used until after
virtio_child_attach_finish completes.

https://mail-index.netbsd.org/source-changes/2023/03/23/msg143799.html

PR kern/58555: Kernel panic during boot when using viocon with PCIe

Pull up following revision(s) (requested by yamaguchi in ticket #139):

	sys/dev/pci/vioscsi.c: revision 1.31
	sys/dev/pci/vio9p.c: revision 1.10
	sys/dev/pci/vioscsi.c: revision 1.32
	sys/dev/pci/vio9p.c: revision 1.11
	sys/dev/pci/vioscsi.c: revision 1.33
	sys/dev/pci/ld_virtio.c: revision 1.31
	sys/dev/virtio/viocon.c: revision 1.6
	sys/dev/pci/vioscsi.c: revision 1.34
	sys/dev/pci/ld_virtio.c: revision 1.32
	sys/dev/virtio/viocon.c: revision 1.7
	sys/dev/virtio/viocon.c: revision 1.8
	sys/dev/pci/vioscsi.c: revision 1.36
	sys/dev/pci/virtioreg.h: revision 1.12
	sys/dev/pci/viornd.c: revision 1.19
	sys/dev/pci/virtio.c: revision 1.66
	sys/dev/pci/virtio.c: revision 1.67
	sys/dev/pci/virtio.c: revision 1.68
	sys/dev/pci/if_vioif.c: revision 1.103
	sys/dev/pci/virtio.c: revision 1.69
	sys/dev/pci/if_vioif.c: revision 1.104
	sys/dev/pci/virtio_pci.c: revision 1.40
	sys/dev/virtio/virtio_mmio.c: revision 1.8
	sys/dev/virtio/virtio_mmio.c: revision 1.9
	sys/dev/pci/viomb.c: revision 1.14
	sys/dev/pci/viomb.c: revision 1.15
	sys/dev/pci/viomb.c: revision 1.17
	sys/dev/pci/viornd.c: revision 1.20
	sys/dev/pci/viornd.c: revision 1.21
	sys/dev/pci/virtiovar.h: revision 1.25
	sys/dev/pci/virtiovar.h: revision 1.26
	sys/dev/pci/virtiovar.h: revision 1.27
	sys/dev/pci/virtiovar.h: revision 1.28
	sys/dev/pci/virtio.c: revision 1.70
	sys/dev/pci/virtio.c: revision 1.71
	sys/dev/pci/virtio.c: revision 1.72
	sys/dev/pci/virtio.c: revision 1.73
	sys/dev/pci/virtio.c: revision 1.74
	sys/dev/pci/virtio_pci.c: revision 1.39

Set virtqueues in virtio_child_attach_finish

The number of virtqueue maybe change in a part of VirtIO devices
(e.g. vioif(4)). And it is fixed after negotiation of features.
So the configuration is moved into the function.

viocon(4): fix not to allocate unused virtqueue

viocon(4) allocates 4 virtqueues but it only uses 2 (0 and 1) queues.

Added functions to set interrupt handler and index into virtqueue

Added check of pointer for allocated memory before release of resource

Setup virtqueues after registering them to virtio_softc
restore fetch of qsize.

Mark as MPSAFE.

virtio(4): Avoid name collision with global intrhand on sparc64.

Pacifies -Werror=shadow.
No functional change intended.

Use PRIuBUSSIZE to print bus_size_t variables.

virtio(4): Fix sizing of virtqueue allocation.
vq->vq_avail[0].ring is a zero-length array, and thus sizeof is zero;
likewise vq->vq_used[0].ring.
Use vq->vq_avail[0].ring[0] and vq->vq_used[0].ring[0] to fix this
and restore the previous allocation sizing logic.
XXX We shouldn't use zero-length arrays here -- they are asking for
trouble like this, and C99 has a standard way to express what we're
actually trying to get at it, flexible array members.
PR kern/57304

virtio(4): Use flexible array members, not zero-length arrays.
This enables the compiler to detect sizeof mistakes like
PR kern/57304.

Use descriptor chain for free slots instead of vq_entry list
Descriptors can be chained by themself. And descriptors added to
avail ring or used ring are already chained. But it was not used
for unused descriptors and another linked list structure named
vq_entry was used.

The chain is also used for unused descriptors to make virtio(4)
simpler.

Added flags to store status of attaching a virtio device

This prevents a panic on reboot after a virtio device had called
virtio_child_attach_failed().

Fix wrong variable names
This fixes build errors in virtio_mmio.c

viocon(4): Show error in assertion failure.

Added functions to set interrupt handler and index into virtqueue

viocon(4): fix not to allocate unused virtqueue

viocon(4) allocates 4 virtqueues but it only uses 2 (0 and 1) queues.

Set virtqueues in virtio_child_attach_finish

The number of virtqueue maybe change in a part of VirtIO devices
(e.g. vioif(4)). And it is fixed after negotiation of features.
So the configuration is moved into the function.

viocon(4): Omit unused sc_dmamap.

viocon(4): Fix bus_dmamap_sync after tx: POSTWRITE, not POSTREAD.

viocon(4): Fix $NetBSD$ rcsid.

viocon(4): Fix tty device number.

viocon(4): New virtio tty driver imported from OpenBSD.

viocon* at virtio?

/dev/ttyVI??

Tested under qemu with:

qemu-system-aarch64 ... \
  -device virtio-serial \
  -chardev socket,path=/tmp/ttyVI00,server=on,wait=off,id=ttyVI00 \
  -device virtconsole,chardev=ttyVI00,name=org.NetBSD.dev.ttyVI00 \
  ...

I updated MAKEDEV.conf to create /dev/ttyVI?? on all ports where it
looks likely to work based on:
(a) having pci or a non-pci virtio attachment,
(b) `qemu-system-$ARCH -M ?' mentioned something resembling the port,
    and
(c) `qemu-system-$ARCH -device virtio-serial' launched without
    complaining about the virtio-serial device.

(Criterion (c) excluded sparc and sparc64.)