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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
