It is easier to use an empty string when the root directory is intended.
Adjust the code to drop use of "/" and NULL and just use and empty
string.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rather than creating a new stream, which gets lost, virtio_fs_dir_open()
should use the existing one. Fix it, so that the fh member is preserved
for future use.
This fixes a problem where the fh value is not preserved, thus causing
a subsequent 'ls' on the same directory to fail.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: #15
The current priority of BOOTDEVP_4_SCAN_FAST means that virtio is
scanned after SCSI. But virtio-scsi provides higher performance.
It seems better to regard virtio has an internal device, since it is
paravirtualised and thus fast. Change its bootdev priority to
BOOTDEVP_2_INTERNAL_FAST
Disable the virtio-fs feature on sandbox, since the virtio queue is not
not yet supported by the emulator.
Signed-off-by: Simon Glass <sjg@chromium.org>
U-Boot only supports a subset of the devices supported by QEMU. For
example, U-Boot does not currently support the vsock device.
It is helpful to see what devices are provided by QEMU and whether there
is a driver for it in U-Boot.
Add a new 'virtio list' command to provide this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Even if U-Boot doesn't have a driver for all of the virtio devices
provided by QEMU, it is still useful to see what they are. Fill out the
table of device types and names, so that 'virtio list' lists them all.
Signed-off-by: Simon Glass <sjg@chromium.org>
When a device type is not supported by U-Boot it is silently ignored.
Add some debugging for this.
Also show the driver features to provide a fuller picture of feature
negotiation.
Series-to: concept
Cover-letter:
virtio: Add support for virtio-scsi
It is often possible to use virtio-blk for block devices, but it is
less flexible than SCSI. SCSI provides a means to probe for multiple
disks through the same interface. It also supports hotplug and other
features.
This series adds a simple virtio-scsi driver for use with QEMU. The new
driver creates a SCSI bus when the virtio buses are scanned. That can be
scanned in turn, using 'scsi scan', to find the available virtio disks.
For this to work, quite a few minor updates are needed in the SCSI
implementation:
- Increase the buffer sizes for commands and sense buffer
- Fix off-by-one error when scanning for devices
- Use REPORT LUN to determine what LUNs are present for a target
- Clean up some open-coded constants
- Make use of a struct to decode the IDENTIFY response
- Clean up of the confusing and error-prone SCSI read/write functions
- Add support for using a scsi disk to the build-qemu/efi scripts
When a SCSI disk is inaccessible (e.g. the LUN is wrong), this is seldom
reported as an error. For example 'part list' does not say 'read error'
but 'unsupported partition type'. Probing the block device results in
each partition-type driver reading blocks, none of which reports the
error. So an attempt is made here to clean this up, so that bad LUNs
show an error.
Another clean-up is to show partition numbers in hex with 'part list',
since the current approach conflicts with the 'part' command.
Some additional x86 debugging is added for the jump from SPL to U-Boot
proper, since this can be confusing when it fails in QEMU.
With all of the above, virtio-scsi can be used on qemu-x86_64 for
loading an OS and associated files, including with standard boot.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
This feature can be useful where the host wants to provide more than one
block device, since it allows all of them to be under one virtio device.
Add an implementation of virtio-scsi
Series-to: concept
Cover-letter:
virtio: Support SCSI over virtio
U-Boot supports virtio-blk and in most cases this is sufficient for
providing access to a disk. However some larger users such as LXD prefer
virtio-scsi since it groups disks together and provides unified probing
of devices.
This series implements this protocol.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
The file include/uapi/linux/virtio_scsi.h contains some useful
definitions for virtio-scsi so bring this in from Linux v6.15
Signed-off-by: Simon Glass <sjg@chromium.org>
Add compatibility function to support a single virtio-fs via the normal
'ls' and 'load' commands. Other commands are not supported for now.
Add a workaround for the fact that virtiofs does not use a block device.
The existing filesystem layer does not support non-block filesystems -
sandbox's hostfs mostly bypasses this code.
Make sure that sandbox does not try to mount a virtio-fs as this does
not work at present. It will require either a fake driver for virtio-fs
which connects to host files, or possibly something involving FUSE.
Series-to: concept
Cover-letter:
virtio: Support virtio-fs
This series introduces support for virtio-fs, a filesystem which
provides access to host files from within a QEMU guest OS.
A new filesystem driver is created with support for the three uclasses
(FS, DIR, FILE). A compatibility layer is added as well, so that the
existing cmdline work as expected.
Only listing directories and reading files are supported so far.
Since sandbox works by using a NULL blk_desc, a workaround is added for
now. Once we switch commands (and bootstd!) over to the new filesystem
approach, this will go away.
It is possible to test this using something like:
./scripts/build-qemu -a x86 -rs -D .
then within U-Boot:
ls virtio 0
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Add an implementation of virtio-fs directories, including looking them
up and reading them.
This requires some information in struct fs_dir_stream to maintain the
state of the directory read.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide access to the virtual queue and some functions for sending
various FUSE messages.
Add myself as a maintainer of virtio.
Signed-off-by: Simon Glass <sjg@chromium.org>
With LSP it is confusing to have two functions named the same in
different files. Rename a few of the legacy ones.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present virtio devices are acknowleged when bound. This results in a
call to virtio_set_status() which uses device-private data in several
cases, e.g. in virtio_pci_get_status()
This data is only allocated when the device is probed, so the access is
either ignored (on QEMU) or results in a crash (on sandbox).
Acknowledging the device so early does not seem to be necessary. Move it
to the pre-probe function instead. Update the test to match. We now have
no coverage to check that VIRTIO_CONFIG_S_ACKNOWLEDGE was actually set.
If we later find it necessary to acknowledge the device while binding,
we can update the uclass and drivers to use plat data instead of priv.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add an emulator driver for block devices, so that sandbox can test these
fully. The emulator uses MMIO to communicate with the controlling virtio
device.
Signed-off-by: Simon Glass <sjg@chromium.org>
The existing sandbox implementation of virtio only tests the basic API.
It is not able to provide a block device, for example.
Add a new implementation which operations at a higher level. It makes
use of the existing MMIO driver to perform virtio operations.
This emulator-device should be the parent of a function-specific
emulator. That emulator uses this MMIO transport to communicate with the
controller:
virtio-blk {
compatible = "sandbox,virtio-blk-emul";
mmio {
compatible = "sandbox,virtio-emul";
};
};
A new UCLASS_VIRTIO_EMUL uclass is created for the child devices, which
implement the actual function (block device, random-number generator,
etc.)
Signed-off-by: Simon Glass <sjg@chromium.org>
The BLK symbol has a few meanings, one of which is that it controls the
driver model portion of a "block device". Rather than having this hidden
symbol be "default y if ..." it should be select'd by the various block
subsystems. Symbols such as PVBLOCK which already select'd BLK are
unchanged".
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
The functions virtio_pci_get_config() and virtio_pci_set_config() don't
take the offset into account when reading the config space. For example
this manifests when U-Boot tries to read the MAC address of the VirtIO
networking device. It reads 6 equa bytes instead of the proper addess.
Fix those functions by taking the offset in the config space into
account.
Fixes: 4135e10732 ("virtio: Add virtio over pci transport driver")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
According to the virtio v1.x "entropy device" specification, a virtio-rng
device is supposed to always return at least one byte of entropy.
However the virtio v0.9 spec does not mention such a requirement.
The Arm Fixed Virtual Platform (FVP) implementation of virtio-rng always
returns 8 bytes less of entropy than requested. If 8 bytes or less are
requested, it will return 0 bytes.
This behaviour makes U-Boot's virtio_rng_read() implementation go into an
endless loop, hanging the system.
Work around this problem by always requesting 8 bytes more than needed,
but only if a previous call to virtqueue_get_buf() returned 0 bytes.
This should never trigger on a v1.x spec compliant implementation, but
fixes the hang on the Arm FVP.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reported-by: Peter Hoyes <peter.hoyes@arm.com>
This name is a little confusing since it suggests that it sets up the
sibling block device. In fact it sets up a bootdev for it. Rename the
function to make this clearer.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
If a driver cannot be bound, provide the driver name in the debug
message. Now the debug message may look like this:
(virtio-pci.l#0): virtio-rng driver not configured
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Sometimes virtio may rely on PCI, or at least that is what the
distro_bootcmd script suggests. Add this in.
Signed-off-by: Simon Glass <sjg@chromium.org>
Devices advertising the VIRTIO_F_IOMMU_PLATFORM feature require
platform-specific handling to configure their DMA transactions.
When handling virtio descriptors for such a device, use bounce
buffers to ensure that the underlying buffers are always aligned
to and padded to PAGE_SIZE in preparation for platform specific
handling at page granularity.
Signed-off-by: Will Deacon <willdeacon@google.com>
[ Paul: pick from the Android tree. Rebase to the upstream ]
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Link: 1eff171e61
Reviewed-by: Simon Glass <sjg@chromium.org>
In preparation for bouncing virtio data for devices advertising the
VIRTIO_F_IOMMU_PLATFORM feature, allocate an array of bounce buffer
structures in the vring, one per descriptor.
Signed-off-by: Will Deacon <willdeacon@google.com>
[ Paul: pick from the Android tree. Rebase to the upstream ]
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Link: 3e052749e7
Reviewed-by: Simon Glass <sjg@chromium.org>
Move the attach and detach logic for manipulating vring descriptors
out into their own functions so that we can later extend these to
bounce the data for devices with VIRTIO_F_IOMMU_PLATFORM set.
Signed-off-by: Will Deacon <willdeacon@google.com>
[ Paul: pick from the Android tree. Rebase to the upstream ]
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Link: f73258a4bf
Reviewed-by: Simon Glass <sjg@chromium.org>
In preparation for explicit bouncing of virtqueue pages for devices
advertising the VIRTIO_F_IOMMU_PLATFORM feature, introduce a couple
of wrappers around virtqueue allocation and freeing operations,
ensuring that buffers are handled in terms of page-size units.
Signed-off-by: Will Deacon <willdeacon@google.com>
[ Paul: pick from the Android tree. Rebase to the upstream ]
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Link: b4bb5227d4
Reviewed-by: Simon Glass <sjg@chromium.org>
The pages backing the virtqueues for virtio PCI devices are not freed
on reset, despite the virtqueue structure being freed as part of the
driver '->priv_auto' destruction at ->remove() time.
Call virtio_pci_del_vqs() from virtio_pci_reset() to free the virtqueue
pages before freeing the virtqueue structure itself.
Signed-off-by: Will Deacon <willdeacon@google.com>
[ Paul: pick from the Android tree. Rebase to the upstream ]
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Link: 5ed54ccd83
Reviewed-by: Simon Glass <sjg@chromium.org>
If we detect the VIRTIO_F_IOMMU_PLATFORM transport feature for a device,
then expose it in the device features.
Signed-off-by: Will Deacon <willdeacon@google.com>
[ Paul: pick from the Android tree. Rebase to the upstream ]
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Link: 9693bd26bf
Reviewed-by: Simon Glass <sjg@chromium.org>
At present virtio tries to attach QEMU services to a bootdev device, which
cannot work. Add a check for this.
Also use bootdev_setup_sibling_blk() to create the bootdev device, since
it allows the correct name to be used and bootdev_get_sibling_blk() to
work as expected.
The bootdev is not created on sandbox since it does have a real virtio
device and it is not possible to read blocks.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: a60f7a3e35 ("bootstd: Add a virtio bootdev")
Reported-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We need extensions to be set up before we start trying to boot any of the
bootdevs. Add a new priority before all the others for tht sort of thing.
Also add a 'none' option, so that the first one is not 0.
While we are here, comment enum bootdev_prio_t fully and expand the test
for the 'bootdev hunt' command.
Signed-off-by: Simon Glass <sjg@chromium.org>
The test code for virtio is fairly simplistic and does not actually create
a block device. Add a way to specify the device type in the device tree.
Add a block device so that we can do more testing.
Signed-off-by: Simon Glass <sjg@chromium.org>
This has a special meaning in driver model. There is clearly a device, so
it does not make sense to return this error code. Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
We already have a function for probing all devices of a specific class,
use it.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
We currently have an if_type (interface type) and a uclass id. These are
closely related and we don't need to have both.
Drop the if_type values and use the uclass ones instead.
Maintain the existing, subtle, one-way conversion between UCLASS_USB and
UCLASS_MASS_STORAGE for now, and add a comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
