Commit Graph

228 Commits

Author SHA1 Message Date
dependabot-preview[bot]
886c0f9093 build(deps): bump libc from 0.2.68 to 0.2.69
Bumps [libc](https://github.com/rust-lang/libc) from 0.2.68 to 0.2.69.
- [Release notes](https://github.com/rust-lang/libc/releases)
- [Commits](https://github.com/rust-lang/libc/compare/0.2.68...0.2.69)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-14 09:27:04 +01:00
Alejandro Jimenez
0fc3936448 arch: Support loading initramfs with PVH boot protocol
Fill and write to guest memory the necessary boot module
structure to allow a guest using the PVH boot protocol
to load an initramfs image.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
2020-04-09 17:28:03 +02:00
Samuel Ortiz
12b036a824 Cargo: Update dependencies for the KVM serialization work
We need the project to rely on kvm-bindings and kvm-ioctls branches
which include the serde derive to be able to serialize and deserialize
some KVM structures.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-04-07 12:26:10 +02:00
Yang Zhong
183529d024 vmm: Cleanup warning from build
Remove unnecessary parentheses from code and this will cleanup
the warning from cargo build.

Signed-off-by: Yang Zhong <yang.zhong@intel.com>
2020-04-07 09:45:31 +02:00
Samuel Ortiz
3eb11069d0 arch: regs: Rename and export create_msr_entries
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-04-03 18:05:18 +01:00
Samuel Ortiz
c3a3490331 arch: regs: Make create_msr_entries more readable
By using simple macros.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-04-03 18:05:18 +01:00
Samuel Ortiz
8fc7bf2953 vmm: Move to the latest linux-loader
Commit 2adddce2 reorganized the crate for a cleaner multi architecture
(x86_64 and aarch64) support.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-03-27 08:48:20 +01:00
Damjan Georgievski
6cce7b9560 arch: load initramfs and populate zero page
* load the initramfs File into the guest memory, aligned to page size
* finally setup the initramfs address and its size into the boot params
  (in configure_64bit_boot)

Signed-off-by: Damjan Georgievski <gdamjan@gmail.com>
2020-03-26 11:59:03 +01:00
Damjan Georgievski
0ce7de3ef5 arch: provide mechanism to get page size
This is a copy of the same code in vm-allocator, until a better place is
found for general use.

Signed-off-by: Damjan Georgievski <gdamjan@gmail.com>
2020-03-26 11:59:03 +01:00
Rob Bradford
8acc15a63c build: Bump vm-memory and linux-loader dependencies
linux-loader depends on vm-memory so must be updated at the same time.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-03-23 14:27:41 +00:00
dependabot-preview[bot]
51f51ea17d build(deps): bump libc from 0.2.67 to 0.2.68
Bumps [libc](https://github.com/rust-lang/libc) from 0.2.67 to 0.2.68.
- [Release notes](https://github.com/rust-lang/libc/releases)
- [Commits](https://github.com/rust-lang/libc/compare/0.2.67...0.2.68)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-03-17 21:36:38 +00:00
Samuel Ortiz
9cf67d133f arch: x86: Always set the bootloader type
We set it to 0xff, which is for unregistered loaders.
The kernel checks that the bootloader ID is set when e.g. loading
ramdisks, so not setting it when we get a bootparams header from the
loader will prevent the kernel from loading ramdisks.

Fixes: #918

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-03-17 19:11:38 +01:00
Samuel Ortiz
ad354700c9 arch: x86: Extract common bootparams settings
We're going to add more common settings, so let's avoid duplication
between the 2 branches.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-03-17 19:11:38 +01:00
Alejandro Jimenez
da084fade7 pvh: Add unit tests for initial sregs and control registers
Validate correct GDT entries, initial segment configuration, and control
register bits that are required by PVH boot protocol.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
2020-03-13 18:29:44 +01:00
Alejandro Jimenez
64941bfcad pvh: Add unit tests for start_info and memory map structures
Expand the unit tests to cover the configure_system() code when
using the PVH boot protocol. Verify the method for adding memory
map table entries in the format specified by PVH boot protocol.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
2020-03-13 18:29:44 +01:00
Alejandro Jimenez
a22bc3559f pvh: Write start_info structure to guest memory
Fill the hvm_start_info and related memory map structures as
specified in the PVH boot protocol. Write the data structures
to guest memory at the GPA that will be stored in %rbx when
the guest starts.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
2020-03-13 18:29:44 +01:00
Alejandro Jimenez
840a9a97ff pvh: Initialize vCPU regs/sregs for PVH boot
Set the initial values of the KVM vCPU registers as specified in
the PVH boot ABI:

https://xenbits.xen.org/docs/unstable/misc/pvh.html

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
2020-03-13 18:29:44 +01:00
Alejandro Jimenez
24f0e42e6a pvh: Introduce EntryPoint struct
In order to properly initialize the kvm regs/sregs structs for
the guest, the load_kernel() return type must specify which
boot protocol to use with the entry point address it returns.

Make load_kernel() return an EntryPoint struct containing the
required information. This structure will later be used
in the vCPU configuration methods to setup the appropriate
initial conditions for the guest.

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
2020-03-13 18:29:44 +01:00
Alejandro Jimenez
98b956886e pvh: Add definitions for PVH boot protocol support
Create supporting definitions to use the hvm start info and memory
map table entry struct definitions from the linux-loader crate in
order to enable PVH boot protocol support

Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
2020-03-13 18:29:44 +01:00
Samuel Ortiz
134e64c612 arch, qcow: Fix 1.42.0 clippy warnings
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-03-13 12:26:15 +00:00
Rob Bradford
f0a3e7c4a1 build: Bump linux-loader and vm-memory dependencies
linux-loader now uses the released vm-memory so we must move to that
version at the same time.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-03-05 11:01:30 +01:00
dependabot-preview[bot]
f190cb05b5 build(deps): bump libc from 0.2.66 to 0.2.67
Bumps [libc](https://github.com/rust-lang/libc) from 0.2.66 to 0.2.67.
- [Release notes](https://github.com/rust-lang/libc/releases)
- [Commits](https://github.com/rust-lang/libc/compare/0.2.66...0.2.67)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-02-21 08:03:30 +00:00
dependabot-preview[bot]
d46c61c5d4 build(deps): bump byteorder from 1.3.2 to 1.3.4
Bumps [byteorder](https://github.com/BurntSushi/byteorder) from 1.3.2 to 1.3.4.
- [Release notes](https://github.com/BurntSushi/byteorder/releases)
- [Changelog](https://github.com/BurntSushi/byteorder/blob/master/CHANGELOG.md)
- [Commits](https://github.com/BurntSushi/byteorder/compare/1.3.2...1.3.4)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-02-07 14:18:07 +00:00
Sebastien Boeuf
3447e226d9 dependencies: bump vm-memory from 4237db3 to f3d1c27
This commit updates Cloud-Hypervisor to rely on the latest version of
the vm-memory crate.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2020-02-06 11:40:45 +01:00
dependabot-preview[bot]
1651cc3953 build(deps): bump kvm-ioctls from 0.4.0 to 0.5.0
Bumps [kvm-ioctls](https://github.com/rust-vmm/kvm-ioctls) from 0.4.0 to 0.5.0.
- [Release notes](https://github.com/rust-vmm/kvm-ioctls/releases)
- [Changelog](https://github.com/rust-vmm/kvm-ioctls/blob/master/CHANGELOG.md)
- [Commits](https://github.com/rust-vmm/kvm-ioctls/compare/v0.4.0...v0.5.0)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-29 10:22:51 +00:00
Sebastien Boeuf
f5a52eda2b arch: Fix map_err losing the inner error
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2020-01-24 12:42:09 +01:00
Rob Bradford
8b500d7873 deps: Bump vm-memory and linux-loader version
The function GuestMemory::end_addr() has been renamed to last_addr()

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-01-15 20:21:22 +01:00
dependabot-preview[bot]
41895d7df1 build(deps): bump rand from 0.7.2 to 0.7.3
Bumps [rand](https://github.com/rust-random/rand) from 0.7.2 to 0.7.3.
- [Release notes](https://github.com/rust-random/rand/releases)
- [Changelog](https://github.com/rust-random/rand/blob/master/CHANGELOG.md)
- [Commits](https://github.com/rust-random/rand/commits)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-13 16:24:25 +00:00
dependabot-preview[bot]
e4ea60dd96 build(deps): bump rand from 0.7.0 to 0.7.2
Bumps [rand](https://github.com/rust-random/rand) from 0.7.0 to 0.7.2.
- [Release notes](https://github.com/rust-random/rand/releases)
- [Changelog](https://github.com/rust-random/rand/blob/master/CHANGELOG.md)
- [Commits](https://github.com/rust-random/rand/compare/0.7.0...0.7.2)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-06 08:32:44 +00:00
Samuel Ortiz
0f21781fbe cargo: Bump the kvm and vmm-sys-util crates
Since the kvm crates now depend on vmm-sys-util, the bump must be
atomic.
The kvm-bindings and ioctls 0.2.0 and 0.4.0 crates come with a few API
changes, one of them being the use of a kvm_ioctls specific error type.
Porting our code to that type makes for a fairly large diff stat.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-29 17:48:02 +00:00
Rob Bradford
0319a4a09a arch: vmm: Move ACPI tables creation to vmm crate
Remove ACPI table creation from arch crate to the vmm crate simplifying
arch::configure_system()

GuestAddress(0) is used to mean no RSDP table rather than adding
complexity with a conditional argument or an Option type as it will
evaluate to a zero value which would be the default anyway.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-11-07 14:02:27 +00:00
Rob Bradford
c999ea6471 arch: x86_64: acpi: Add basic processor details
Add basic processor details to the DSDT table. The code has to be
slightly convoluted (with the second pass over the cpu_devices vector)
in order to keep the objects alive long enough in order to be able to
take their reference.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-11-05 14:45:21 +01:00
Sebastien Boeuf
587a420429 cargo: Update to the latest kvm-ioctls version
We need to rely on the latest kvm-ioctls version to benefit from the
recent addition of unregister_ioevent(), allowing us to detach a
previously registered eventfd to a PIO or MMIO guest address.

Because of this update, we had to modify the current constraint we had
on the vmm-sys-util crate, using ">= 0.1.1" instead of being strictly
tied to "0.2.0".

Once the dependency conflict resolved, this commit took care of fixing
build issues caused by recent modification of kvm-ioctls relying on
EventFd reference instead of RawFd.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-10-31 09:30:59 +01:00
Rob Bradford
7c2c4fb3fc acpi_tables: aml: Rename to_bytes() to to_aml_bytes()
To avoid a clash with to_bytes() for the unsigned integer types that is
coming in a future release.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-10-24 10:55:02 +01:00
Rob Bradford
ad60fe110b arch: x86_64: acpi: Mark 64-bit device area uncacheable
This region was erroneously marked as cacheable.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-10-24 10:55:02 +01:00
Rob Bradford
025f1f9d9b arch: x86_64: acpi: Remove 16-bit PCI range
We don't use this range and it shouldn't be included in our DSDT.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-10-24 10:55:02 +01:00
Rob Bradford
555ac68ea5 arch: x86_64: acpi: Generate DSDT programatically
This was verified by comparing the ASL from disassembling the DSDT
before and after. All the individual AML components themselves are also
unit tested.

Fixes: #352

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-10-24 10:55:02 +01:00
Sebastien Boeuf
03352f45f9 arch: Create ACPI IORT table
The virtual IOMMU exposed through virtio-iommu device has a dependency
on ACPI. It needs to expose the device ID of the virtio-iommu device,
and all the other devices attached to this virtual IOMMU. The IDs are
expressed from a PCI bus perspective, based on segment, bus, device and
function.

The guest relies on the topology description provided by the IORT table
to attach devices to the virtio-iommu device.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-10-07 10:12:07 +02:00
Rob Bradford
9356af80c6 arch: Mark the PCI MMCONFIG region as reserved in the E820 tables
The PCI Express Firmware specification says that the region may
be included in the E820 tables (but it must always be in the ACPI
tables.)

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-30 18:00:31 +01:00
Rob Bradford
6a4a931b9e arch: acpi: Reserve the PCI MMCONFIG region
The PCI Express Firmware spec says that the region to be used for PCI
MMCONFIG should be reserved as part of the motherboard's resources in
the ACPI tables.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-30 18:00:31 +01:00
Rob Bradford
038f198129 arch: acpi: Fix off-by-one error in size of PCI device region
When comparing offsets it is necessry to increment by one to give the
appropriate size.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-30 18:00:31 +01:00
Rob Bradford
c0ca3b6b8e arch: acpi, layout: Correctly calculate and expose PCI MMCONFIG area
The PCI MMCONFIG area must be below 4GiB and must not be part of the
device space. Shrink the device area and put the PCI MMCONFIG region
above it.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-30 18:00:31 +01:00
Rob Bradford
a9eb352aea arch: acpi: Patch the 32-bit PCI device area in the APCI table
Patch the table with the currently used constants. This will be relevant
when we want to adjust the size of the PCI device area to accomodate the
PCI MMCONFIG region.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-30 18:00:31 +01:00
Rob Bradford
162791b571 vmm, arch: Use IOAPIC constants from layout in DeviceManager
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-27 11:48:30 -07:00
Rob Bradford
8207b2e97d arch: Move addresses for GDT and IDT tables to layout module
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-27 11:48:30 -07:00
Rob Bradford
1bc47507b7 arch: Move initial page table addresses to layout module
These are part of RAM and are used as the initial page table entries for
booting the OS and firmware (identity mapping.)

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-27 11:48:30 -07:00
Rob Bradford
5ba61f6d5e arch: Move address of MPTABLE to layout module
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-27 11:48:30 -07:00
Rob Bradford
6d6e290000 arch: Move APIC and IOAPIC addresses into layout
Move the addresses used for the APIC and IOAPIC into our new memory
layout module.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-27 11:48:30 -07:00
Rob Bradford
0e7a1fc923 arch, vmm: Start documenting major regions of RAM and reserved memory
Using the existing layout module start documenting the major regions of
RAM and those areas that are reserved. Some of the constants have also
been renamed to be more consistent and some functions that returned
constant variables have been replaced.

Future commits will move more constants into this file to make it the
canonical source of information about the memory layout.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-27 08:55:47 -07:00
Rob Bradford
ff1cb11946 arch: Use if-let notation
To keep updated clippy happy.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-27 08:05:56 -07:00
Rob Bradford
b488d4859b arch: x86_64: Fix E820 table for RAM
The last byte was missing from the E820 RAM area. This was due to the
function using the last address relative to the first address in the
range to calculate the size. This incorrectly calculated the size by
one. This produced incorrect E820 tables like this:

[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001ffffffe] usable

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-19 10:43:55 +01:00
Rob Bradford
f0360c92d9 arch: acpi: Set the upper device range based on RAM levels
After the 32-bit gap the memory is shared between the devices and the
RAM. Ensure that the ACPI tables correctly indicate where the RAM ends
and the device area starts by patching the precompiled tables. We get
the following valid output now from the PCI bus probing (8GiB guest)

[    0.317757] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
[    0.319035] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
[    0.320215] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
[    0.321431] pci_bus 0000:00: resource 7 [mem 0xc0000000-0xfebfffff window]
[    0.322613] pci_bus 0000:00: resource 8 [mem 0x240000000-0xfffffffff window]

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-19 10:43:55 +01:00
Rob Bradford
f9b0875a60 arch: acpi: Correct range for the 32-bit device hole
There was an off-by-error in the result making the hole one byte too
big and ending at an address too high.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-19 10:43:55 +01:00
Rob Bradford
eb60106159 arch: acpi: Correct starting length of MCFG table
The starting length of the MCFG table was too long resulting in the
kernel trying to get extra MCFG entries from the table that weren't
there resulting in the following error message from the kernel:

PCI: no memory for MCFG entries

The MCFG table also has an 8 bytes of padding at the start before the
table begins.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-18 06:27:59 +02:00
Rob Bradford
9661e8da5d build: Really make the acpi feature disableable
The command "cargo build --no-default-features" does not recursively
disable the default features across the workspace. Instead add an acpi
feature at the top-level, making it default, and then make that feature
conditional on all the crate acpi features.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-05 08:58:47 -07:00
Rob Bradford
9e764fc091 vmm, arch, devices: Put ACPI support behind a default feature
Put the ACPI support behind a feature and ensure that the code compiles
without that feature by adding an extra build to Travis.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-03 19:18:49 +02:00
Rob Bradford
5a187ee2c2 x86_64/devices: acpi: Add support for ACPI shutdown & reboot
Add an I/O port "device" to handle requests from the kernel to shutdown
or trigger a reboot, borrowing an I/O used for ACPI on the Q35 platform.
The details of this I/O port are included in the FADT
(SLEEP_STATUS_REG/SLEEP_CONTROL_REG/RESET_REG) with the details of the
value to write in the FADT for reset (RESET_VALUE) and in the DSDT for
shutdown (S5 -> 0x05)

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-03 19:18:49 +02:00
Sebastien Boeuf
011496bda0 arch: acpi: Fix legacy interrupt for serial device
The DSDT must declare the interrupt used by the serial device. This
helps the guest kernel matching the right interrupt to the 8250 serial
device. This is mandatory in case the IRQ routing is handled by ACPI, as
we must let ACPI know what do do with pin based interrupts.

One thing to notice, if we were using acpi=noirq from the kernel command
line, this would mean ACPI is not in charge of the IRQ routing, and the
device COM1 declaration would not be needed.

One additional requirement is to provide the appropriate interrupt
source override for the legacy ISA interrupts (0-15), which will give
the right information to the guest kernel about how to allocate the
associated IRQs.

Because we want to keep the MADT as simple as possible, and given that
our only device requiring pin based interrupt is the serial device, we
choose to only define the pin 4.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-09-03 19:18:49 +02:00
Rob Bradford
2610f4353d arch: acpi: Only add ACPI COM1 device if serial is turned on
Only add the ACPI PNP device for the COM1 serial port if it is not
turned off with "--serial off"

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-03 19:18:49 +02:00
Rob Bradford
15387cd96a arch: x86_64: acpi: Add DSDT table entries for PCI and COM1
Currently this has a hardcoded range from 32GiB to 64GiB for the 64-bit PCI
range. It should range from the top of ram to 64GiB.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-03 19:18:49 +02:00
Rob Bradford
638bf0378c arch: x86_64: acpi: Generate MCFG table
The MCFG table contains some PCI configuration details in particular
details of where the enhanced configuration space is.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-03 19:18:49 +02:00
Rob Bradford
98f81c36ec arch: x86_64: acpi: Generate MADT aka APIC table
This provides important APIC configuration details for the CPU. Even
though it duplicates some of the information already included in the
mptable it is necessary when booting with ACPI as the mptable is not
used.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-03 19:18:49 +02:00
Rob Bradford
ee83c2d44e arch: x86_64: Generate basic ACPI tables
Generate very basic ACPI tables for HW reduced ACPI.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-09-03 19:18:49 +02:00
Rob Bradford
26a210a83a arch: x86_64: Fix EBDA adddress
This was set to the MP table address rather than the start of the EBDA.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-08-19 16:04:34 +01:00
Sebastien Boeuf
658c076eb2 linters: Fix clippy issues
Latest clippy version complains about our existing code for the
following reasons:

- trait objects without an explicit `dyn` are deprecated
- `...` range patterns are deprecated
- lint `clippy::const_static_lifetime` has been renamed to
  `clippy::redundant_static_lifetimes`
- unnecessary `unsafe` block
- unneeded return statement

All these issues have been fixed through this patch, and rustfmt has
been run to cleanup potential formatting errors due to those changes.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-08-15 09:10:04 -07:00
Rob Bradford
513d2fdcf6 arch: x86_64: Update linux-loader crate
The linux-loader crate has been updated with a regnerated bootparams.rs
which has changed the API slightly. Update to the latest linux-loader
and adapt the code to reflect the changes:

* e820_map is renamed to e820_table (and all similar variables updated)
* e820entry is renamed to boot_e820_entry
* The E820 type constants are not no longer included

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-08-15 10:42:44 +02:00
Rob Bradford
ac950d9a97 build: Bulk update dependencies
Update all dependencies with "cargo upgrade" with the exception of
vmm-sys-utils which needs some extra porting work.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-08-02 15:22:37 +02:00
Sebastien Boeuf
8c4c162109 arch: x86_64: Set MTRR default memory type as WB
In the context of VFIO, we use Vt-d, which means we rely on an IOMMU.
Depending on the IOMMU capability, and in particular if it is not able
to perform SC (Snooping Control), the memory will not be tagged as WB
by KVM, but instead the vCPU will rely on its MTRR/PAT MSRs to find the
appropriate way of interact with specific memory regions.

Because when Vt-d is not involved KVM sets the memory as WB (write-back)
the VMM should set the memory default as WB. That's why this patch sets
the MSR MTRRdefType with the default memory type being WB.

One thing that it is worth noting is that we might have to specifically
create some UC (uncacheable) regions if we see some issues with the
ranges corresponding to the MMIO ranges that should trap.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-08-01 20:14:46 +02:00
Samuel Ortiz
fa41ddd94f arch: Add a Reserved memory region to the memory hole
We add a Reserved region type at the end of the memory hole to prevent
32-bit devices allocations to overlap with architectural address ranges
like IOAPIC, TSS or APIC ones.

Eventually we should remove that reserved range by allocating all the
architectural ranges before letting 32-bit devices use the memory hole.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-07-25 11:45:38 +01:00
Samuel Ortiz
299d887856 arch: Add SubRegion memory type
We want to be able to differentiate between memory regions that must be
managed separately from the main address space (e.g. the 32-bit memory
hole) and ones that are reserved (i.e. from which we don't want to allow
the VMM to allocate address ranges.

We are going to use a reserved memory region for restricting the 32-bit
memory hole from expanding beyond the IOAPIC and TSS addresses.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-07-25 11:45:38 +01:00
Sebastien Boeuf
f98a69f42e vm-allocator: Introduce an MMIO hole address allocator
With this new AddressAllocator as part of the SystemAllocator, the
VMM can now decide with finer granularity where to place memory.

By allocating the RAM and the hole into the MMIO address space, we
ensure that no memory will be allocated by accident where the RAM or
where the hole is.
And by creating the new MMIO hole address space, we create a subset
of the entire MMIO address space where we can place 32 bits BARs for
example.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-07-22 09:51:16 -07:00
Rob Bradford
18d52869c5 arch: x86_64: Make unit tests pass
With the adoption for rust-vmm linux-loader crate some small changes
were needed to update the unit tests to reflect this change:

* configure_system now takes an extra parameter
* the e820 entry structure comes from the linux-loader crate

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 17:09:05 +02:00
Rob Bradford
c4c8b9314d build: Switch over to using rust-vmm linux-loader crate
With everything now merged upstream we no longer need to rely on Cathy's
fork.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-06-13 11:28:20 +01:00
Cathy Zhang
429b53a672 vmm: Add bzimage loader support
VMM may load different format kernel image to start guest, we currently
only have elf loader support, so add bzimage loader support in case
that VMM would like to load bzimage.

Signed-off-by: Cathy Zhang <cathy.zhang@intel.com>
2019-06-13 11:28:20 +01:00
Sebastien Boeuf
13a065d2cd dep: Rely on latest kvm-ioctls crate
In order to have access to the newly added signal_msi() function
from the kvm-ioctls crate, this commit updates the version of the
kvm-ioctls to the latest one.

Because set_user_memory_region() has been swtiched to "unsafe", we
also need to handle this small change in our cloud-hypervisor code
directly.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-06-06 15:27:35 +01:00
Samuel Ortiz
9299502955 cloud-hypervisor: Switch to crates.io kvm-ioctls
Fixes: #15

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-05-15 05:59:08 +01:00
Samuel Ortiz
040ea5432d cloud-hypervisor: Add proper licensing
Add the BSD and Apache license.
Make all crosvm references point to the BSD license.
Add the right copyrights and identifier to our VMM code.
Add Intel copyright to the vm-virtio and pci crates.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-05-09 15:44:17 +02:00
Samuel Ortiz
b56b4ca834 cloud-hypervisor: Add the architecture crates
Both crates are based on Firecracker commit 9cdb5b2.
They are ported to the new memory model and tests have been fixed
accordingly.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-05-07 18:40:40 +02:00