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>
Legacy PCI interrupts should be level triggered, not edge triggered.
The reverted change was done as part of a series of patches during
debugging of virtio-pci differences from virtio-mmio, but this was not
the actual root cause of the problems.
BUG=None
TEST=Boot crosvm on x86-64 and verify virtio devices still work
This reverts commit 9357ceab6a.
Change-Id: If1bf6e48d63fe352f0b914f5bdb2e346ab210369
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1297840
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>
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>
This reverts commit c8986f14a8.
Re-land the virtio PCI conversion after the preceding fixes.
BUG=chromium:854766
TEST=Boot crosvm on nami and kevin
Change-Id: I3699e3ed1a45cecc99c51e352d0cf0c32bc4116f
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1265862
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>
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>
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 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>
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>
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>
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>
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>
Device allocations have to skip the gap so they don't collide with
things like the APIC.
BUG=863490
TEST=Resize a gedit window on APL for a minute and make sure there isn't
a crash.
Change-Id: Ia8185bcdbb6c18e13d02be317ae4d48c73288661
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1168400
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
PCI devices will require interrupts, allow this by passing a vector of
IRQs to the mptable so the guest kernel can find the IRQs.
Change-Id: I9fa8a2ed0a34089e631441570521082ffde9c4ef
Reviewed-on: https://chromium-review.googlesource.com/1072578
Commit-Ready: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
PCI adds a configuration space to the existing memory mapped IO
supported by BusDevices.
Add the ability to set configuration space as optional to the BusDevice
trait so that ProxyDevice can be shared.
PCI devices can have more than one memory mapped region. Expand the bus
so that it has the ability to pass an absolute address instead of an
offset. This will allow the PCI device to know which BAR is being
written to.
Change-Id: I055cd516c49a74316a9547df471290f05d865b0a
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1103663
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Combine GPU buffer allocation with the system resource allocator making
life easier as only one allocator needs to get passed to the execute
function.
Change-Id: I199eb0fd6b99b629aaec1ae3295e8a1942da5309
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1099856
The fix passes through cache-related CPU entries 2, 4, 0x80000005
and 0x80000006 similar to how QEMU does it.
Note passing this cpuid info itself is not sufficient unless
CPU vendor is something Linux kernel recognizes. Therefore, I am
removing cute spoofing of the vendor id, allowing host value to
pass through.
I believe it is generally a bad idea to spoof vendor id as lots of
kernel and user space code gets confused and may take unoptimized paths.
The corollary is that removing the spoofing may have unintended
consequences correctness- and performance-wise. I would appreciate
recommendation on additional testing.
BUG=chromium:859678
TEST=lscpu in Guest, 'cargo test'
Change-Id: I6963b00d9eecf49fb4578bcc75ad744c3099f045
Reviewed-on: https://chromium-review.googlesource.com/1125529
Commit-Ready: Slava Malyugin <slavamn@chromium.org>
Tested-by: Slava Malyugin <slavamn@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Allow IRQs to be assigned before creating device manager.
For PCI, we need to add devices with interrupts before MMIO setup. Add
the ability to tell the architecture device manager about IRQs that we
have stolen.
There was only one function in device_manager and all of its state is
now delegated to the resource allocator, remove it.
Change-Id: I9afa0e3081a20cb024551ef18ae34fe76a1ef39d
Reviewed-on: https://chromium-review.googlesource.com/1089720
Commit-Ready: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
This fixes an issue on kevin where if we start on a little core, the
kernel doesn't like the generic ARMv8 target cpu type for some reason. To
fix this we must query the preferred type from the vm device first and
supply that to the vcpu init ioctl.
We need to change the signature of the configure_vcpu method to pass
in the vm object even though we aren't using it on x86.
BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on kevin
Change-Id: I460cb9db62a8805bb88f838956aa4f1c69183961
Reviewed-on: https://chromium-review.googlesource.com/982996
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
We were setting LME (Long Mode Enabled) but not LMA (Long Mode Active).
New kernels have a check in the kvm code that disallows this brokenness.
Change-Id: Ic8950c8748ead81201223c19404fdd2c8d80f7dc
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/985733
Reviewed-by: Zach Reizner <zachr@chromium.org>
The official name is "crosvm", not "CrOSVM".
BUG=None
TEST=None
Change-Id: I21f200d8224c9a8fee53011a63ff4ad165128904
Reviewed-on: https://chromium-review.googlesource.com/976941
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
This creates a trait that different architectures can implement to
support running Linux VMs.
In the implementation on X86 we remove some error and return errors
from lower-level modules as appropriate. These modules now implement
the Error trait so we can get meaningful descriptions without an extra
error from the calling function. This still keeps all the ifdefs in
linux.rs for now until we have another implementation to use for ARM.
BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on caroline
Change-Id: If24bcc83e25f9127d6aea68f9272e639296aad8b
Reviewed-on: https://chromium-review.googlesource.com/952368
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This is useful for describing errors that we pass up.
BUG=chromium:797868
TEST=build_tests passes on all architectures
TEST=crosvm runs on caroline
Change-Id: Ied456015e74830d3f1f465fca1151682c9148eb5
Reviewed-on: https://chromium-review.googlesource.com/961603
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This is in preparation to make different architectures implement a
trait, but for now it's just moving code out of linux.rs and into
x86_64 trait. A few new functions were required which will become
part of the trait interface. There's still a lot of ugly ifdefs
everywhere that should go away in subsequent CLs.
BUG=chromium:797868
TEST=./build_test
TEST=run crosvm on caroline
Change-Id: Ifc95d4eb84f64ebacb4481a172524d94dc96b7bb
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/942084
Reviewed-by: Zach Reizner <zachr@chromium.org>
Implement the std::error::Error Trait for Error types within the
x86_64 crate. We will make use of these implementations later on when
we are using the architecture Trait to pass architecture-specific
errors up with meaningful descriptions.
BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on caroline
Change-Id: I7a30db69437990608e3a0f5e6e3a200ef6c2d0c3
Reviewed-on: https://chromium-review.googlesource.com/932976
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
It does not make sense to have users of the API limit number of cpuid
entries retrieved. Just have KVM select reasonable upper limit and
return the true number.
TEST=cargo test --features plugin; cargo test -p kvm
BUG=chromium:800626
Change-Id: I8ab7e8d901bc408d17c23bfe798d89f921488673
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/933242
Reviewed-by: Zach Reizner <zachr@chromium.org>
The initalization code in crosvm used two-level page table
in long mode, with last entry covering 1GB. This assumed
presence of 1GB pages support ('pdpe1gb' in /proc/cpuinfo).
Some CPUs don't have it.
BUG=none
TEST=reproduced bug on Celeron N3150 (Braswell), verified
VM boots on it with fix
Change-Id: I6014c7ea236d8daf95e9f09b68beb7935a267aa3
Reviewed-on: https://chromium-review.googlesource.com/936323
Commit-Ready: Slava Malyugin <slavamn@chromium.org>
Tested-by: Slava Malyugin <slavamn@chromium.org>
Reviewed-by: Slava Malyugin <slavamn@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
We want to be able to run 64-bit ARM kernels using a 32-bit version of
crosvm, to make it more consistent use a u64 to represent
GuestAddress.
BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on caroline
Change-Id: I43bf993592caf46891e3e5e05258ab70b6bf3045
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/896398
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Recent Linux kernel's fail to start if the mptable is at the start of
RAM (address 0x00). Avoid putting the mptable there so that crosvm can
boot 4.14+ kernels. The kernel scans the last kilobyte of RAM after the
first, move the mptable there.
Change-Id: Ia00f49e7a4cbd0fb3719c21b757e8fdca65584e8
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/780045
The table grew with the addition of the 16 mpc_intsrc structures.
Correct the `compute_mp_size` function, the end check, and add a unit
test for the not having enough memory.
Change-Id: I1ff268629a47a422f50aefef9d6aa95121b94d59
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/777710
Reviewed-by: Slava Malyugin <slavamn@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The mptable inherited from kvmtool had some missing pieces. On top of that,
crosvm does not use KVM_SET_GSI_ROUTING. The addresses makes mptable match
the default routing in host kernel and removes "noapic".
TEST=cargo build (--release). tatl boot tested on 4.4.0 and 4.4.9
Change-Id: Ibc55abf245cd9d8fca601da204d5a189321c09c7
Reviewed-on: https://chromium-review.googlesource.com/772820
Commit-Ready: Slava Malyugin <slavamn@google.com>
Tested-by: Slava Malyugin <slavamn@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Mutable references being declared mutable themselves is unnecessary and
now generates a warning.
Change-Id: I29c7652fb86e17a8eda21efc728dd09b726c304f
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/717733
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Not all types are safe to read from guest memory. Any type with a
reference or pointer will be initialized to random bits that don't refer
to a valid address. This can cause dangling pointer and general
unsafe behavior.
To fix this, limit types that can be read with read_obj to those that
implement the unsafe trait `DataInit`. Provide implementations of
`DataInit` for intrinsic types that are obviously safe to initialize
with random data.
Implement the needed traits for bootparam types as they are read from
the kernel image directly.
Change-Id: I1040f5bc1b2fc4c58c87d8a2ce3f618edcf6f9b1
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/540750
Reviewed-by: Zach Reizner <zachr@chromium.org>
A few places were passing a reference to a reference, which just gets
compiled out anyways.
Some other places where passing `|e| ErrorName(e)` as a closure when
just `ErrorName` would be more succinct.
Change-Id: Ic097a81b956ef82b29fc1a15196c245bee61c251
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/510782
Reviewed-by: Zach Reizner <zachr@chromium.org>
Add a module for accessing guest memory.
This module will replace all the slices that are used to access it
currently as those slices aren't valid because the memory is volatile
and a volatile slice doesn't exist in rust.
Modify the existing users so they no longer depend on the deprecated slice
access.
Change-Id: Ic0e86dacf66f68bd88ed9cc197cb14e45ada891d
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/509919
