This CL adds a crate `sync` containing a type sync::Mutex which wraps
the standard library Mutex and mirrors the same methods, except that
they panic where the standard library would return a PoisonError. This
API codifies our error handling strategy around poisoned mutexes in
crosvm.
- Crosvm releases are built with panic=abort so poisoning never occurs.
A panic while a mutex is held (or ever) takes down the entire process.
Thus we would like for code not to have to consider the possibility of
poison.
- We could ask developers to always write `.lock().unwrap()` on a
standard library mutex. However, we would like to stigmatize the use
of unwrap. It is confusing to permit unwrap but only on mutex lock
results. During code review it may not always be obvious whether a
particular unwrap is unwrapping a mutex lock result or a different
error that should be handled in a more principled way.
Developers should feel free to use sync::Mutex anywhere in crosvm that
they would otherwise be using std::sync::Mutex.
TEST=boot linux
Change-Id: I9727b6f8fee439edb4a8d52cf19d59acf04d990f
Reviewed-on: https://chromium-review.googlesource.com/1359923
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Hopefully the changes are self-explanatory and uncontroversial. This
eliminates much of the noise from `cargo clippy` and, for my purposes,
gives me a reasonable way to use it as a tool when writing and reviewing
code.
Here is the Clippy invocation I was using:
cargo +nightly clippy -- -W clippy::correctness -A renamed_and_removed_lints -Aclippy::{blacklisted_name,borrowed_box,cast_lossless,cast_ptr_alignment,enum_variant_names,identity_op,if_same_then_else,mut_from_ref,needless_pass_by_value,new_without_default,new_without_default_derive,or_fun_call,ptr_arg,should_implement_trait,single_match,too_many_arguments,trivially_copy_pass_by_ref,unreadable_literal,unsafe_vector_initialization,useless_transmute}
TEST=cargo check --features wl-dmabuf,gpu,usb-emulation
TEST=boot linux
Change-Id: I55eb1b4a72beb2f762480e3333a921909314a0a2
Reviewed-on: https://chromium-review.googlesource.com/1356911
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
These duplicate the doc comments found in `trait PciDevice`. I am
removing them because a sensible reader would already assume that they
have fallen out of sync with the doc comments in the trait, and thus
refer to the trait definition anyway.
TEST=none
Change-Id: Id86936a6f2a1b6c78a000b107bb4fc8ed78e40f9
Reviewed-on: https://chromium-review.googlesource.com/1355350
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Our virtio devices are all "modern" (no legacy/transitional support).
Add VIRTIO_F_VERSION_1 to the features() handler for all virtio devices
that didn't already have it.
This lets us remove the hack that forced VIRTIO_F_VERSION_1 on for all
devices.
BUG=None
TEST=build_test; boot crosvm on kevin
Change-Id: I008926a9075679aae46069aa37a14504f10e8584
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1313013
Reviewed-by: Zach Reizner <zachr@chromium.org>
When wl-dmabuf is not enabled, rustc complains about unused imports and
enum values. Add compiler directives to silence the warnings.
BUG=None
TEST='cargo build', 'emerge-nami crosvm'
Change-Id: Ib39735d329f8aa835c0b5842b10bfe78d0e578d9
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1327827
The virtio specification only defines feature bits in the 0-63 range
currently, so we can represent the features as a u64. The Linux kernel
makes the same simplifying assumption, and very few features have been
defined beyond the first 32 bits, so this is probably safe for a while.
This allows the device models to be simplified, since they no longer
need to deal with the features paging mechanism (it is handled by the
generic virtio transport code).
BUG=None
TEST=build_test; boot termina on kevin
Change-Id: I6fd86907b2bdf494466c205e85072ebfeb7f5b73
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1313012
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Refactor existing code to use msg_socket.
BUG=None
TEST=local build and run
Change-Id: Iee72326b330e035303f679e1aedd6e5d18ad4f8a
Reviewed-on: https://chromium-review.googlesource.com/1260260
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This matches the definitions from the virtio specification and makes
balloon consistent with the other virtio devices in crosvm.
BUG=None
TEST=build_test.py
Change-Id: I9dd6b6ec981944e28eaf6bc92332db5ec326433b
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1313011
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
All devices have been converted to PCI, so we don't need MmioDevice.
BUG=chromium:854766
TEST=Boot crosvm on kevin and verify virtio devices still work
Change-Id: Ib6400e15bdb2153d14795de3cb0bfbf1845a8891
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1281832
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Rust 1.30.0 ships a new rustfmt that causes a few more formatting
changes.
BUG=None
TEST=Run kokoro tests with updated Rust version
Change-Id: I803765ec0f3d2447f627b1e990bce438512367f7
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1307816
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Register the irqfd with resample support so that we can correctly
emulate level-triggered interrupts. This requires each PciDevice to
listen for interrupt_resample events and re-assert the IRQ eventfd if it
should still be active.
BUG=None
TEST=Boot crosvm on x86-64 and arm devices
Change-Id: I5cf8d1d1705cf675b453962c00d2d606801fee91
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1298654
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
File exposes sync_all() and sync_data() functions, which map to fsync()
and fdatasync(), but these functions are not in a trait (they are just
implemented directly on File), so they can't be implemented and used in
a generic way for QcowFile.
Add a new trait, FileSync, that exposes a fsync() function that may be
used in the virtio block model. Previously, we were translating a block
flush request into a call to File's flush() function, but this just
flushes internal Rust library buffers to the file descriptor; it didn't
actually result in a fsync() call. Using the new trait, we can cause an
actual fsync() to occur for raw files, as intended. QcowFile was
already safe, since its flush() function actually calls sync_all() under
the hood.
BUG=None
TEST=sync with raw disk and verify fsync() in strace output
Change-Id: I9bee2c0d2df3747aac1e7d9ec7d9b46a7862dc48
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1297839
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
If a BackBuffer has some gpu_renderer_resource, attach the backing
through to virgl to allow resources to be transfered in the future.
BUG=chromium:892261
TEST=eglgears_x11, xterm, xeyes
Change-Id: I9c4310da8eba73ec69dbaeba340b362c22fb21a0
Reviewed-on: https://chromium-review.googlesource.com/1288960
Commit-Ready: David Riley <davidriley@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Make the Minijail part of the PCI device tuple optional so that an empty
jail is not created for --disable-sandbox.
BUG=None
TEST=Boot crosvm in both --multiprocess and --disable-sandbox modes
Change-Id: Ibb3f2dbf33ca19910ee7448ea823b2772e09ecc5
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1290289
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Our branch of the 3.18 kernel has FALLOC_FL_PUNCH_HOLE disabled for the
ext4 filesystem, which means that systems running that kernel always
take the fallback path of writing buffers full of zeroes. This is not
necessary for the Discard command, since it is just a hint and is not
required to actually zero the blocks.
Split the WriteZeroes trait up into a new PunchHole trait, which
corresponds to fallocate() with FALLOC_FL_PUNCH_HOLE, and use the new
trait to implement the virtio block Discard command.
BUG=chromium:896314
TEST=`mkfs.btrfs /dev/vdb` and verify the desired fallocate() is used
and no write() calls are issued when inducing a failure
Change-Id: I67fd9a132758d8d766531ccca8358c7fe67b0460
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1286224
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The virtio PCI spec (4.1.4.5.1 Device Requirements: ISR status
capability) says:
"The device MUST reset ISR status to 0 on driver read."
BUG=chromium:854766
TEST=None
Change-Id: I92a1ddccfc8e44bed7f4a16e3cfd11b946629e22
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1260252
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The virtio PCI spec (4.1.5.2 Notifying The Device) says:
"The driver notifies the device by writing the 16-bit virtqueue index
of this virtqueue to the Queue Notify address."
We were previously registering the notify address specifying
NoDatamatch; switch this to a 16-bit match of the queue index to follow
the specification.
BUG=chromium:854766
TEST=Boot crosvm with virtio devices converted to PCI
Change-Id: Ic950a8c7751268f7fcc21d5c37b0afc859f1e6d0
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1265861
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Now that cargo fmt has landed, run it over everything at once to bring
rust source to the standard formatting.
TEST=cargo test
BUG=None
Change-Id: Ic95a48725e5a40dcbd33ba6d5aef2bd01e91865b
Reviewed-on: https://chromium-review.googlesource.com/1259287
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
capset2 has many new features. We currently hardcode num_capsets
to 1, however our Mesa/guest kernel/virglrenderer are new enough
to support caps v2.
We could attempt to do negotiation (see virtio_gpu_virgl_get_num_capset
in QEMU), but virtio::gpu::Gpu::get_config actually comes before
virtio::gpu::Gpu::activate. To support older Mesa/guest kernel/virglrenderer
configurations, this must be refactored.
BUG=none
TEST=get a gles31 context on tatl
Change-Id: I8d9ed54774a63da2ec5a4ba86187330521785566
Reviewed-on: https://chromium-review.googlesource.com/1258323
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The virtio PCI transport requires that the queue_size configuration
value returns the maximum supported queue size on reset; it uses 0 to
indicate an unavailable queue.
Queue::size is write-only via the existing MmioDevice (the driver must
always write a queue size during initialization), so there should be no
difference in behavior when using MMIO virtio devices.
Change-Id: I5b77e0d84f0bc7b854e33aaeb34ff011af226103
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1237363
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This will be used on ARM.
Change-Id: I61206b761f49f963f0cce706268379ceae1a0239
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1241540
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The current PciRoot is only workable for the legacy I/O port 0xCF8
access mechanism; factor out the config access mechanism part of PciRoot
into PciConfigIo so that we can add a MMIO-based access mechanism for
ARM.
Change-Id: I87756b0ab31070d8717c76d419957bf5ea5d75ad
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1241539
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Most of PCI configuration space should be read only; initialize the
writable_bits field accordingly.
Change-Id: I67f93d81cfbac6000db51663bdf76e54aeac08f3
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1240659
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The add_capability() function was using the normal PCI configuration
write_byte() function, which enforces read-only regions. This won't
work once the appropriate regions of config space are marked as read
only in the following commit, so add an internal-only helper function to
access bytes without applying writable_bits.
Change-Id: If61f79cd80950bf517d69c18aaf98c2e76841a56
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1240658
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Return the BAR number rather than the register offset within PCI config
space.
Change-Id: I6e965c5fe7218abe6986b461731f18abb34894c1
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1240653
Reviewed-by: Dylan Reid <dgreid@chromium.org>
VirtioDevices and potentially others need to register ioeventfds that
will be triggered when guests write to certain addresses. Allow
PciDevices to return an array of ioeventfds that the VM can install.
Change-Id: I2524c4e8c04f75a8d7868cac998304aecbb29c40
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1237360
Commit-Ready: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
PciDevice implementations will have file descriptors that need to be
preserved across the minijail fork.
Change-Id: I0b1f5b827b55c4d8960ffa95331b82f9c692f304
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1237359
Reviewed-by: Dylan Reid <dgreid@chromium.org>
PCI class codes are made up of three fields: class, subclass, and
programming interface. Some class/subclass combinations do not define
any programming interfaces, so add an optional parameter to specify the
value and use 0 if it is not provided.
Change-Id: Ib4000eafe2d7d003ed5753d7b0ea05e16fd06130
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1237358
Reviewed-by: Dylan Reid <dgreid@chromium.org>
passing everything in to the pci code is getting annoying. Instead build
it up in arch which already has access to all the needed resources.
Change-Id: If42f994443c4f11152fca8da16f27fa4cd80580d
Reviewed-on: https://chromium-review.googlesource.com/1237357
Commit-Ready: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Rather than querying the flush timerfd state repeatedly on every write,
just track the state in a variable. This avoids an extra
timerfd_gettime() syscall on every write.
BUG=None
TEST=Verify that the flush timer still fires via strace
Change-Id: I5437d26570de466f05b496d3e0dce08a521c4fde
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1247443
Reviewed-by: Dylan Reid <dgreid@chromium.org>
To fully meet the requirements laid out by the virtio specification, we
need to fail write commands for devices that expose VIRTIO_BLK_F_RO with
a specific error code of VIRTIO_BLK_S_IOERR. Pipe the read_only status
down into the worker and the request execute function so that it can be
checked and return the correct error code.
BUG=chromium:872973
TEST=Attempt to write to read-only /dev/vda in termina
Change-Id: I98c8ad17fde497e5a529d9e65096fb4ef022fd65
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1211062
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Otherwise, the flush timer case of the PollContext continues to fire
repeatedly, since the timerfd remains readable.
BUG=None
TEST=Verify that crosvm virtio_blk thread no longer pins the CPU after
writes are done
Change-Id: I693346c078e07b97e30083f34d00be75fa93841d
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1232295
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The Scm object was made to reduce the number of heap allocations in
the hot paths of poll loops, at the cost of some code complexity. As it
turns out, the number of file descriptors being sent or received is
usually just one or limited to a fixed amount that can easily be covered
with a fixed size stack allocated buffer.
This change implements that solution, with heap allocation as a backup
in the rare case that many file descriptors must be sent or received.
This change also moves the msg and cmsg manipulation code out of C and
into pure Rust. The move was necessary to allocate the correct amount
of buffer space at compile time. It also improves safety by reducing the
scope of unsafe code. Deleting the code for building the C library is
also a nice bonus.
Finally, the removal of the commonly used Scm struct required
transitioning existing usage to the ScmSocket trait based methods. This
includes all those changes.
TEST=cargo test
BUG=None
Change-Id: If27ba297f5416dd9b8bc686ce740866912fa0aa0
Reviewed-on: https://chromium-review.googlesource.com/1186146
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
If the guest doesn't issue a flush command after a write, insert one.
This will mainly help qcow backed files. However, it is a good idea for
block devices as well, it narrows the window for data loss.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Change-Id: I1d6eaeda6fd5038ec994ed882e870ae025e3c151
Reviewed-on: https://chromium-review.googlesource.com/1211126
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Sandboxing only works when started as chronos via concierge client. If
started directly via crosvm as root, the jail will not have proper group
permissions to access the Wayland socket.
BUG=chromium:837073
TEST=build with --features=gpu; null_platform_test without --disable-sandbox
CQ-DEPEND=CL:1213779
Change-Id: I6331f7ae1f5b99d31ad44cf158f72337294771f0
Reviewed-on: https://chromium-review.googlesource.com/1181168
Commit-Ready: David Riley <davidriley@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The virtio PCI specification places requirements on the PCI subsystem
IDs, so allow PCI devices to specify them in PciConfiguration.
Change-Id: I70bc6ad4333ba3601db2831fef03483bcaea70ff
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1208156
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The status register is actually the high 16 bits of register index
STATUS_REG (1). Adjust the STATUS_REG_CAPABILITIES_USED_MASK value
accordingly so it is bit 4 within the high 16 bits.
Change-Id: I3fb695a577bae754eda5640224ef335c44b119eb
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1208152
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Currently VirtioDevice was only used by MmioDevice. Move it to a
separate file to allow it to be used by a PCI implementation in the
following commits.
Change-Id: Ie2de92d8876fdaa31d71341714681212d52a618c
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1208690
Commit-Ready: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Discard and Write Zeroes commands have been added to the virtio block
specification:
88c8553838
Implement both commands using the WriteZeroes trait.
BUG=chromium:850998
TEST=fstrim within termina on a writable qcow image
Change-Id: I33e54e303202328c10f7f2d6e69ab19f419f3998
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1188680
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Also fix the misleading add_capability() comment. The standard PCI
capability header is just two bytes (capability type and next pointer);
the length byte is only part of the vendor-specific capability (09h).
More importantly, the current implementation of add_capability() already
inserts the two-byte standard header, so the caller should not provide
it as part of cap_data.
BUG=None
TEST=cargo test -p devices
Change-Id: Id3517d021bfe29d08ff664d66455b15cf07af1d1
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1197069
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The virtio 1.0 feature flag is defined as a shift count, not a mask.
While we're at it, change the virtio gpu features() function to the
avail_features style used in other devices for consistency.
BUG=None
TEST=None
Change-Id: I704d9676cfe5f13d9a2f83eb9160937e94070d1e
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1198224
Reviewed-by: Zach Reizner <zachr@chromium.org>
Define a struct to represent the virtio block configuration as defined
in the current revision of the specification. Only the capacity field
is set; all other fields are defaulted to 0, which should be safe, since
they are all controlled by feature flags that our device does not
advertise.
This is prep work for adding discard/write zeroes support to the block
device, since these commands require additional config fields that will
be added at the end of the config struct.
BUG=chromium:850998
TEST=cargo test -p devices; verify that container still boots and
reports the correct size
Change-Id: I8beb76195e446eb3dcbf1a99cc246ddd8cc8a7df
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1175235
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The virtio block specification defines the VIRTIO_BLK_F_RO feature bit
to indicate read-only block devices. Plumb the read-only status of
block devices from the crosvm frontend into the virtio block device and
populate the flag when appropriate.
BUG=chromium:872973
TEST=Verify lsblk output in guest has the correct RO values
Change-Id: I23af87cce8020641cd702adca6e8ff9fdd2b8220
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1170306
Reviewed-by: Zach Reizner <zachr@chromium.org>
This matches other virtio device models (net, p9, vsock) and makes it
easier to add flags conditionally at device creation time.
BUG=chromium:872973
TEST=cargo test -p devices
Change-Id: I65b3f37c220fae44a3f6b397acc6c0eec2b70bf2
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1170305
Reviewed-by: Zach Reizner <zachr@chromium.org>
