Prepares config for upstreaming.
- Adds Ser/De to Config.
- Makes some of Config's members as unix only.
- Moves platform specific gpu validation code.
- Rearranges imports.
Windows serializes/deserializes Config to send over a Tube.
BUG=b:213146388
TEST=built on downstream windows and presubmit
Change-Id: I7300ee68c7a59feacd43a7d4a82ef2758f3cca3b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3735636
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
Enable most of modules under `irqchip` as well as `tsc` to work with
windows since all their dependencies have been completed. They were
already working for unix.
The test `irqchip::userspace::tests::irq_event_tokens` fails on wine,
however, it work on windows and unix natively.
The test `tsc::calibrate::tests::test_frequency_higher_than_u32` fails
for hosts with cpu>64, since the windows implementation for setting
thread affinity does not support cpu>64.
BUG=b:237024070
TEST=Ran `tools/run_tests --target=host --arch=win64`
Change-Id: I15d8f3c3256e89f89efbe64dbe2ad809fcd90a72
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3737456
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vaibhav Nagarnaik <vnagarnaik@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Windows serializes/deserializes these types to send over a Tube.
BUG=b:213146388
TEST=built on downstream windows and presubmit
Change-Id: Ib9ca4cbb2758a997788c4bab46d573a532e8e3d4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3735635
Commit-Queue: Vikram Auradkar <auradkar@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The original Pit code encoded the start value of a timer into the
count_load_time field as a number of nanoseconds since the start of
the host's monotonic time value. Instead, we can use the PitCounter's
creation_time as the epoch. This makes the math look a bit more sensible
and removes the use of the non-portable clock_gettime() function.
Before
======
get_channel_state():
count_load_time = get_monotonic_time() - start.elapsed()
=== count_load_time = now() - (now() - start)
=== count_load_time = start
set_channel_state():
start = now() - (get_monotonic_time() - count_load_time)
=== start = now() - now() + count_load_time
=== start = count_load_time
After
=====
get_channel_state():
count_load_time = start - creation_time
set_channel_state():
start = creation_time + count_load_time
BUG=chromium:908689
BUG=b:213149155
TEST=cargo test -p devices pit
TEST=tools/run_tests --target=host --arch=win64
Change-Id: I5468d1d964a04b1ce96979ed583b729d139e1005
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3723804
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Implement Default for Fpu to initialize the floating point registers to
their officially documented reset values, and use the default Fpu values
to initialize all VCPU floating point state.
These are the same values as used in the previous setup_fpu() function,
so there is no change in behavior. (We now set the FPU state for both
BIOS and non-BIOS, but since the FPU values should match the ones used
at CPU reset, it should not cause any actual behavior change.)
BUG=b:237095693
TEST=boot x86-64 Linux kernel
Change-Id: I4eb656822d8fa4730203970aee178043c19af9ff
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3723799
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Rather than having a single vcpu_init instance that is used for all
VCPUs, make vcpu_init into a Vec so it can store different initial state
for each VCPU. This allows us to set up e.g. bootstrap processor state
differently than other processors, and it also means that the VcpuInit
struct doesn't need to be Copy.
BUG=b:237095693
TEST=Boot Linux with >1 CPU
Change-Id: I0ebfdc2dbd84d0817e3f75c2c852e4320b9e77c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3723798
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
At one point the capability was a VmCap and not a HypervisorCap. Because
we don't build these files on Windows yet, this wasn't immediately
obvious. This CL cleans up the issue.
BUG=b:213152505
TEST=fixes applied downstream.
Change-Id: Icdf0c3292ff976ddb74791a158bb65380f1697d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3732380
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Compiler warnings that only occur when compiled with feature chromeos are fixed.
Fixed=b:235772995
TEST=none
Change-Id: Ie1f120798d0812e7e54984292ccccdac2477a030
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3731294
Commit-Queue: Zihan Chen <zihanchen@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Adds a link to the crosvm_control docs in the library source.
BUG=b:236909264
TEST=cq
Change-Id: I144e4a3823d20cea2c1087b71c2efa86e7029de3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3729256
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Kameron Lutes <kalutes@chromium.org>
This will land after references to --no-legacy flag disappears.
BUG=b:236574949
TEST=boot volteer-manatee
Change-Id: Ic2b8c601f7a0d193f52b8b096195341ca88f4ef2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3715084
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
windows parses gpu code quite differently. The cl also move some unix
only(because they expect the file /dev/kvm to be around) tests.
BUG=b:213146388
TEST=presubmit
Change-Id: I1f9b11485e09808f4748c8b49d0bc8b29e8ca525
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3732374
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
This CL adds a command-line flag to crosm that locks the entire guest
memory, per http://go/host-assisted-vm-swap.
The change relies on existing balloon device code that punches holes
within the guest memory region upon "inflate".
BUG=b:236210703
TEST=manual startup, roblox+instagram and various chrome sessions
Change-Id: I11e0e5b0b0cb6450f47124a6a8b6c4befd9de6ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3725731
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Marciano Gimenez <raging@google.com>
Auto-Submit: Alexandre Marciano Gimenez <raging@google.com>
Similar to WHPX, haxm requires an accurate (calibrated) leaf value to
make the guest clocksource work accurately.
BUG=b:213152505
TEST=battle tested downstream
Change-Id: I55a45c00758b2112aced6185970ad43df060d0ba
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3731287
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Reviewed-by: Vaibhav Nagarnaik <vnagarnaik@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
There have been two evolutions of providing the TSC cpuid leaf
(aka 0x15) to the guest.
a) For CrosVM on Windows, we have been providing the leaf
unconditionally. Furthermore, we've not been using the
exact host leaf; instead, we calibrate the TSC frequency
and provide that value in the leaf. This was done because
the actual cpuid leaf values are not as accurate as
we needed them to be to drive a guest clocksource.
b) In CrosVM mainline, 4080aaf9b3
introduced the flag enable_pnp / enable_pnp_data, and
provides the exact host 0x15 leaf to the guest if the
flag is enabled.
This CL adds a new hypervisor capability (CalibratedTscLeafRequired) to control
whether or not the calibrated TSC leaf should be used, in addition to a new CLI
option to force it on hypervisors where it isn't enabled by default. The new
option is `--force_calibrated_tsc_leaf`.
BUG=b:213152505
TEST=builds upstream, battletested downstream on WHPX.
Change-Id: I611422808a9e10578c0ddcbd211ae902f937685f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3698993
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Still need to enable:
* balloon (try_clone not implemented)
* console (Need to enable Serial)
* snd (Unix code not conditionally compiled out)
* gpu (Waiting for graphics team to upstream)
* vhost-user block and handler
The vhost mod is also being built now, but the vhost devices that don't
build on Windows have been disabled.
BUG=b:237011316
TEST=ran "./tools/run_tests --target=host --arch=win64 --verbose"
Change-Id: I3d06a9d49b4bdae14dea47fcfa030834b55925ac
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3723797
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Richard Zhang <rizhang@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
This is required so the guest can know which resolutions are supported
for encoded formats.
BUG=b:169295147
TEST=ffplay from Linux guest can start streaming.
Change-Id: I6f86108efbc8971f3ee4b9ec494cec16ebce323d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3716017
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Move thread affinity and other scheduler configuration into a new
set_vcpu_thread_scheduling() function, and call that function right away
when each vcpu thread is created. This moves the affinity-related code
out of the runnable_vcpu() function, making the responsibilities of each
function clearer.
The same thread affinity, core scheduling, cgroup membership, and
real-time scheduling priority are applied in the same order as before,
but these are all set up front before any other vcpu setup.
BUG=None
TEST=crosvm run -c 4 bzImage
Change-Id: I825f71fd4a07165190ffe2a04b35ceffe3dc0308
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3719325
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
This is the structure for the "device" command, and since we are going
to introduce a "devices" one we would like to take over the name.
BUG=b:218223240
TEST=cargo check
Change-Id: I9e3ef1ad3738f7090126bbfc215930e82547ac3b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3716016
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Switch VmMemoryRequest and FsMappingRequest to use base::Protection to
express permissions, in preparation for unifying the APIs.
BUG=b:201745804
TEST=boot ARCVM and crostini
Change-Id: Id001abbd2dde19aa14fcf1643f25abafdd66a2e6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3716337
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
One more script that needs to run on python 3.8 so we can run test
for windows on luci.
BUG=b:234173142
TEST=vpython3 tools/run_tests
Change-Id: I0348a567b2edec3b5e3fca77f316f39d1e924adc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3723037
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
The cvt crate dependency was removed and replaced with a manual
check of the returned value in StreamChannel::inner_read.
Bug: b:231641496
Upstream-Crate: base/src/sys/unix
Change-Id: Ie4cfa14b4b4821923828a97546d6c2a767b9356f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3707390
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Clarissa Garvey <clarissagarvey@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
We accidentally removed nanosecond precision at some point (likely when
I redid the formatter). This CL fixes that.
BUG=b:237004396
TEST=tested format string in the playground
Change-Id: Iaa502c13c34c9cc8f4b7be05821a63c8f10cb360
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3722782
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Add support to create multiple PCM devices in virtio-snd
in addition to multiple streams support. Android will
use different PCM devices for different use cases.
Change num_{output,input}_streams to number of streams
per device.
Changes:
- Add num_{output, input}_devices support in ChromeOS's backend
- Update num_{output, input}_streams in ChromeOS's backend
- Update help message
BUG=b:236924546
TEST=unit test for Parameters parsing
TEST=`aplay -l` with different number of output devices/streams
TEST=`arecord -l` with different number of input devices/streams
Change-Id: I29a3ecc6002ce669c5f771ef490f10419848380e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3722007
Commit-Queue: Pattara Teerapong <pteerapong@chromium.org>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
AsRawDescriptor is a very generic trait and some of the types we want to
use as input sources already implement it for other purposes.
ReadNotifier makes the purpose of the returned descriptor obvious (wait
for some data), so use it instead.
BUG=b:228912920
TEST=console device works in both regular and vhost-user modes.
Change-Id: I68a4ce05be449e07ea71e7cb472e8cda00e9d84d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3671059
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Move the async runner of the vhost-user console device into its own
module and implement a regular VirtioDevice on top of it. This makes
both the virtio and vhost-user console devices use the same
ConsoleDevice struct and runner code, and also removes the input reader
thread from our virtio implementation.
The Windows support cannot use async and thus still needs the older
console device, so keep it around for now even though it is not used on
Linux.
BUG=b:228912920
TEST=virtio console device is working (with input) on Linux.
TEST=vhost-user console device is working (with input) on Linux.
TEST=VVU console device is working (with input) on Linux.
Change-Id: I0a8dfe6c507ef9b765d8d1cdf9870cdcd128a9aa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3600172
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Use an INT3 (0xCC) instruction to cause the example to exit after
printing the message. This is more convenient than having to manually
kill crosvm from another terminal.
BUG=None
TEST=Run baremetal and observe that it exits
Change-Id: I4baeecca41d156c82bb1e1b27d0f8c2ba93959f9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3691966
Reviewed-by: Anton Romanov <romanton@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Fix loading of the example baremetal kernel with the fixed ELF kernel
loader:
- Remove the "RAM" address space so virtual and physical address match.
- Remove the 0x200-byte padding now that entry point address is used.
BUG=b:234155022
TEST=Run baremetal as in tools/examples/baremetal/README.md
Change-Id: I61394cdf4bf71f91736da5a636b0088ecfe78c84
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3691965
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Anton Romanov <romanton@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously, we were loading ELF kernels at the provided kernel_start
address plus the p_paddr (physical address) field of each program
header. This resulted in the kernel being loaded after a big gap of
zero bytes, which accidentally worked on x86_64 because 0x00 0x00
encodes a valid instruction, and the entry point was at the beginning of
the first section, so execution would effectively "nop slide" its way
from the supposed entry point all the way to the actual beginning of the
correct code. In addition, the Linux kernel entry point is compiled as
position-independent code, so the mismatched address did not matter.
Fix this by loading ELF kernels at whatever physical address they
specify, without adding any extra offset. The load_kernel() function
still accepts a start address, but this is now used simply to verify
that the ELF file does not try to load any sections outside of the
desired kernel region.
As a demonstration, we can look at the instructions at the kernel's
declared entry point (0x1000000 for a normal x86-64 Linux kernel in ELF
format) by attaching to the gdb stub and running:
(gdb) disas 0x1000000,+8
With the old behavior, we get purely 0x00 0x00 opcodes, decoding as:
0x0000000001000000: add BYTE PTR [rax],al
0x0000000001000002: add BYTE PTR [rax],al
0x0000000001000004: add BYTE PTR [rax],al
0x0000000001000006: add BYTE PTR [rax],al
With the new behavior, we get the correct entry point instructions:
0x0000000001000000: lea rsp,[rip+0x1203f51] # 0x2203f58
0x0000000001000007: lea rdi,[rip+0xfffffffffffffff2] # 0x1000000
BUG=b:234155022
TEST=cargo test -p kernel_loader
TEST=Boot x86-64 ELF vmlinux kernel
Change-Id: Iae4c8db022674e6311e54dffe479a1ed430a1ef4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3673612
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Anton Romanov <romanton@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This will be used in a follow-up commit to set the initial instruction
pointer register.
BUG=b:234155022
TEST=tools/presubmit
Change-Id: I3a75f3929beb9e7dbccea0a0d245cf0bfebfe99f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3673614
Reviewed-by: Anton Romanov <romanton@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This allows passing the entry point of the kernel as the initial
instruction pointer value to each vcpu initialization call.
BUG=b:234155022
TEST=Boot vmlinux ELF kernel on x86-64
Change-Id: I6e7bd710ff304601dc6ec56acc0380cbef72c055
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3711619
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Replace the automatically derived Default with a manual implementation
so we can set bit 1 of the flags register to 1. This is architecturally
defined to be an always-1 bit (for reasons dating back to 8080/8085
source-level compatibility on the 8086), so we should not create a value
where bit 1 isn't set.
BUG=b:234155022
TEST=tools/presubmit
Change-Id: I7835e5a04385654a667b55e2e2ea2121b5807288
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3717524
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
