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>
In deallocate_cluster(), we call set_cluster_refcount() to unref the
cluster that is being deallocated, but we never actually added the
deallocated cluster to the unref_clusters list. Add clusters whose
refcounts reach 0 to the unref_clusters list as well.
Also add mremap() to the seccomp whitelist for the block device, since
this is being triggered by libc realloc() and other devices already
include it in the whitelist.
BUG=chromium:850998
TEST=cargo test -p qcow; test crosvm on nami and verify that qcow file
size stays bounded when creating a 1 GB file and deleting it
repeatedly
Change-Id: I1bdd96b2176dc13069417e0ac77f0768f9f26012
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1259404
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This reverts commit d635acbaf3.
This commit seems to be responsible for introducing hung tasks in tests,
so let's revert it for now to get the tests green and debug it offline.
BUG=chromium:891806
TEST=None
Change-Id: I83504058baeae00909d9fb4f4bb704a144a0dfaf
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1259408
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Change the main create_virtio_devs() function to create virtio devices
using the PCI transport rather than MMIO.
BUG=chromium:854766
TEST=Boot crosvm and verify that all virtio devices still work
Change-Id: I9a6e60b21edea1e5ac2b3ae5c91793d45cf5063a
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1241541
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Implement the generic PCI host as supported by Linux and described in
Documentation/devicetree/bindings/pci/host-generic-pci.txt in the kernel
source tree.
Also increase the ARM64 MMIO region size from 0x10000 to 0x100000 to
allow enough space for several virtio PCI devices.
Change-Id: I2f0a9b04356cce912874a06e62b4f3a59cbb08f1
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1244398
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
VirtioPci uses 0x4000 bytes of MMIO space per device, so the existing
allocation of 0x10000 was only enough for 4 devices; extend the MMIO
region to allow for more devices.
Change-Id: I0cc44edacc5f435510ab8ae9b38a925a0ee5d008
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1240654
Reviewed-by: Dylan Reid <dgreid@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>
MPTABLE needs the PCI device number, not the IRQ; modify the information
passed via pci_irqs so that it contains a (device index, interrupt pin)
tuple.
Change-Id: Ia1dcb478cdab6654087925093ef9d1204edb21c9
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1237362
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>
Track the clean/dirty state of the L1 table and the refcount table to
avoid writing them out and doing an extra fsyncdata() if nothing has
changed.
BUG=None
TEST=Manually verify strace output contains only the expected fsyncs
Change-Id: I20bdd250024039a5b4142605462a8977ced1efcc
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1247442
Reviewed-by: Dylan Reid <dgreid@chromium.org>
When reading and writing refcount blocks and pointer tables, the
QcowRawFile implementation was performing many individual read() and
write() system calls (one per table entry), which is quite inefficient.
Use the read_*_into functions from ReadBytesExt for reads and BufWriter
for writes to buffer the I/O into larger chunks.
BUG=None
TEST=Manually verify larger reads/writes with strace
Change-Id: I276963db0a4e91b22335c26c799ae8fb55bf6ad3
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1247441
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This changes ARM_TRIPLE to armv7a-cros-linux-gnueabihf because we are
renaming the abi from armv7a-cros-linux-gnueabi to armv7a-cros-linux-gnueabihf
BUG=chromium:711369
TEST=FEATURES="test" emerge-kevin crosvm
Change-Id: I4b4352f7cba47ba6492e733dd1d16796dadd3275
Reviewed-on: https://chromium-review.googlesource.com/1241538
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Yunlian Jiang <yunlian@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Rust's libc crate exports the default off_t definition on 32-bit
platforms, rather than the _FILE_OFFSET_BITS=64 variant, so we need to
explicitly use the 64-bit API to get support for files larger than 2 GB.
The Rust libc crate does not currently export fallocate64, so declare it
ourselves for now. This declaration can be removed once fallocate64 is
added upstream.
BUG=chromium:850998
TEST=Run fstrim on Kevin (32-bit ARM) and verify it works
Change-Id: Id0aa7a6e7e6080f4c53e10c3ad1d105f15ee2549
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1238850
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>
Add newfstatat for x86 and fstatat64 for arm to the seccomp policy file
for the 9p device and server program.
BUG=chromium:886535
TEST=`vmc share termina foo` and then `ls /mnt/shared` inside the VM
works
Change-Id: I6871f54ae885e080dca0ea5751987d59c55a59d6
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1232556
Reviewed-by: Stephen Barber <smbarber@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>
The path to the wayland socket changed, so the previous whitelist based
on the connect() arg2 sockaddr_un size now fails.
BUG=None
TEST=Verify that release build of crosvm starts again on chromebook
Change-Id: I3c30977e7c1487b937d69e1dbce4b7fd87136978
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1234827
Reviewed-by: David Riley <davidriley@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Zach Reizner <zachr@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>
"devices: block: Flush a minute after a write" introduced new timerfd_
syscalls into the block device but did not add them to the seccomp
whitelist.
BUG=chromium:885238
TEST=Run crosvm in multiprocess mode and verify that it boots
Change-Id: I1568946c64d86ab7dba535a430a8cbe235f64454
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1231513
Commit-Ready: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This program makes figuring out the state of a qcow file easier.
Change-Id: If297eb0cd835a86d8f284d3aef3d7e962e095726
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1207455
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Being able to access the state of the qcow file makes debugging easier.
These functions will be used from a helper program in the following
commit.
Change-Id: I1db7ddaeaff1c83363513a2c55c44a1825833634
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1207454
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
For example, if the wayland socket is given as /run/wayland-0, the
entire /run/ directory will be bind mounted into the sandbox as
/wayland/. The wayland device will then be told to open the socket at
/wayland/wayland-0. If the /run/wayland-0 file is removed and a new
socket is opened in its place, as in a chrome crash, the
/wayland/wayland-0 socket will open the new socket rather than the one
belonging to the expire process.
TEST=vmc start termina; chrome://inducebrowsercrashforrealz;
vsh termina; start wayland application
BUG=chromium:884398
Change-Id: I259eb2f7e29ee6b61836133ec1c3a110c5575957
Reviewed-on: https://chromium-review.googlesource.com/1227063
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@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>
This allows users to only arm timers if not already armed.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Change-Id: I8d7c6a7643a2ae2ce4b5679107bfd2be6e4adf3a
Reviewed-on: https://chromium-review.googlesource.com/1214442
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Cache the address lookup and refcount tables in RAM. This removes an
absurd number of system calls required for accessing the qcow image as
previously each lookup required reading from at least three locations on
disk. Now the disk will only be accessed when there is a cache miss or
when the structure of the disk need to be updated; when a cluster is
added or removed.
The L1 address lookup table and the refcount table are both read at
creation time and kept in memory. For now all caches are committed to
disk only when the file is flushed. Later a timer will be added to
periodically flush the caches to disk so there is less window for data
loss.
The L2 and refcount blocks are cached as full clusters. Those clusters
are kept in the cache until a flush or they need to be evicted to make
room for a new entry. The eviction is currently very simple, writing
back the first entry in the cache in whatever order a hashmap iterator
uses. This can be improved, but the speedup is already enough that it
seems acceptable to start.
Change-Id: Ifcc55f243961d54eb1c6255b975a1529e2e987af
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1207453
Reviewed-by: Chirantan Ekbote <chirantan@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 refcounting helper breaks out management of the refcounts and
caching the refcount blocks.
Change-Id: I6e75fbe0eb47277ccf7a93af026b5020089875db
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1207452
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
The `VecCache` struct will be used to represent the file clusters in
caches. It ties a vector to a state of dirty or clean.
Change-Id: I474eb67d2ad9f086da638ecc385ccce74737d3b9
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1207451
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
The raw file struct will be used to hold enough state for basic
operations. This will allow mutating the file without taking a mutable
reference to an entire QcowFile.
Change-Id: Ia0a86537915da039274923df2f85c22d191b9969
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1207450
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Chirantan Ekbote <chirantan@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>
When setting up IO, accept an optional PciRoot device to put on the IO
bus.
For aarch64, it's currently ignored. For x86_64, it will be added at
0xcf8.
break up mmio device creation and registration
Moving forward registration will be handled by the architecture specific
code. However, creation will be handled by the common code. To make that
easier split up the two steps so a list of devices is created, then each
is registered later.
Start moving to a model where the configuration generates a set of
components that are passed to the architecture. The architecture will
crate a VM from the components.
Break up the big run_config function and move architecture specific
parts to the various architectures.
This doesn't refactor the function calls each architecture makes, but
moves the setup flow in to the arch impls so that they can diverge in
the future.
Change-Id: I5b10d092896606796dc0c9afc5e34a1b288b867b
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1099860
Commit-Ready: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
