x86 AMD SEV-ES: Copy UEFI #VC IDT entry

AMD SEV-ES introduces a new #VC exception that handles the communication
between guest and host. UEFI already implements a #VC handler so there
is no need to

x86 AMD SEV-ES: Copy UEFI #VC IDT entry

AMD SEV-ES introduces a new #VC exception that handles the communication
between guest and host. UEFI already implements a #VC handler so there
is no need to re-implement it in KVM-Unit-Tests. To reuse this #VC
handler, this commit reads UEFI's IDT, copy the #VC IDT entry into
KVM-Unit-Tests' IDT.

Reusing UEFI #VC handler is a temporary workaround, and the long-term
solution is to implement a #VC handler in KVM-Unit-Tests so it does not
depend on specific UEFI's #VC handler. However, we still believe that
the current approach is good as an intermediate solution, because it
unlocks a lot of testing and we do not expect that testing to be
inherently tied to the UEFI's #VC handler.

In this commit, load_idt() can work and now guest crashes in
setup_page_table(), which will be fixed by follow-up commits.

Signed-off-by: Zixuan Wang <zixuanwang@google.com>
Message-Id: <20211004204931.1537823-16-zxwang42@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

x86 AMD SEV: Initial support

AMD Secure Encrypted Virtualization (SEV) is a hardware accelerated
memory encryption feature that protects guest VMs from host attacks.

This commit provides set up cod

x86 AMD SEV: Initial support

AMD Secure Encrypted Virtualization (SEV) is a hardware accelerated
memory encryption feature that protects guest VMs from host attacks.

This commit provides set up code and a test case for AMD SEV. The set up
code checks if SEV is supported and enabled, and then sets SEV c-bit for
each page table entry.

To run the test, use

./x86/efi/run x86/amd_sev.efi -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x3 -machine memory-encryption=sev0

Co-developed-by: Hyunwook (Wooky) Baek <baekhw@google.com>
Signed-off-by: Hyunwook (Wooky) Baek <baekhw@google.com>
Signed-off-by: Zixuan Wang <zixuanwang@google.com>
Message-Id: <20211004204931.1537823-13-zxwang42@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

x86 UEFI: Set up page tables

UEFI sets up page tables before executing EFI application binaries.
These page tables do not allow user space code to access kernel space
memory. But `x86/syscall.c` tes

x86 UEFI: Set up page tables

UEFI sets up page tables before executing EFI application binaries.
These page tables do not allow user space code to access kernel space
memory. But `x86/syscall.c` test case places a user space function
`syscall_tf_user32` inside kernel space memory. When using UEFI page
tables, fetching this kernel memory from user space triggers a #PF
fault, which is not expected by this test case.

KVM-Unit-Tests defines page tables that allow such behavior. So the
solution to this problem is to load KVM-Unit-Tests' page tables:

1. Copy the page table definition from `x86/cstart64.S`
2. Update page table entries with runtime memory addresses
3. Update CR3 register with the new page table root address

Since this commit, `x86/syscall.c` can run in UEFI and generate same
output as in Seabios, using the following command:

./x86/efi/run ./x86/syscall.efi --cpu Opteron_G1,vendor=AuthenticAMD

Signed-off-by: Zixuan Wang <zixuanwang@google.com>
Message-Id: <20211004204931.1537823-11-zxwang42@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

x86 UEFI: Set up RSDP after UEFI boot up

Root system description pointer (RSDP) is a data structure used in the
ACPI programming interface. In BIOS, RSDP is located within a
predefined memory area,

x86 UEFI: Set up RSDP after UEFI boot up

Root system description pointer (RSDP) is a data structure used in the
ACPI programming interface. In BIOS, RSDP is located within a
predefined memory area, so a program can scan the memory area and find
RSDP. But in UEFI, RSDP may not appear in that memory area, instead, a
program should find it in the EFI system table.

This commit provides RSDP set up code in UEFI:
1. Read RSDP from EFI system table
2. Pass RSDP pointer to find_acpi_table_attr() function

From this commit, the `x86/s3.c` test can run in UEFI and generates
similar output as in Seabios, note that:
1. In its output, memory addresses are different than Seabios's, this
is because EFI application starts from a dynamic runtime address,
not a fixed predefined memory address
2. There is a short delay (~5 secs) after the test case prints "PM1a
event registers" line. This test case sleeps for a few seconds
and then wakes up, so give it a few seconds to run.

Signed-off-by: Zixuan Wang <zixuanwang@google.com>
Message-Id: <20211004204931.1537823-10-zxwang42@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

x86 UEFI: Set up memory allocator

KVM-Unit-Tests library implements a memory allocator which requires
two arguments to set up (See `lib/alloc_phys.c:phys_alloc_init()` for
more details):
1. A bas

x86 UEFI: Set up memory allocator

KVM-Unit-Tests library implements a memory allocator which requires
two arguments to set up (See `lib/alloc_phys.c:phys_alloc_init()` for
more details):
1. A base (start) physical address
2. Size of available memory for allocation

To get this memory info, we scan all the memory regions returned by
`LibMemoryMap()`, find out the largest free memory region and use it for
memory allocation.

After retrieving this memory info, we call `ExitBootServices` so that
KVM-Unit-Tests has full control of the machine, and UEFI will not touch
the memory after this point.

Starting from this commit, `x86/hypercall.c` test case can run in UEFI
and generates the same output as in Seabios.

Co-developed-by: Varad Gautam <varad.gautam@suse.com>
Signed-off-by: Varad Gautam <varad.gautam@suse.com>
Signed-off-by: Zixuan Wang <zixuanwang@google.com>
Message-Id: <20211004204931.1537823-9-zxwang42@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

x86 UEFI: Load GDT and TSS after UEFI boot up

Global Descriptor Table (GDT) defines x86 memory areas, e.g. memory area
for data or code. UEFI has a different GDT compared to KVM-Unit-Tests,
e.g., in

x86 UEFI: Load GDT and TSS after UEFI boot up

Global Descriptor Table (GDT) defines x86 memory areas, e.g. memory area
for data or code. UEFI has a different GDT compared to KVM-Unit-Tests,
e.g., in UEFI, 3rd GDT entry defines a code segment, while in
KVM-Unit-Tests, 3rd GDT entry is data segment.

Without loading KVM-Unit-Tests GDT, the UEFI GDT is used and is
incompatible with KVM-Unit-Tests. This causes QEMU to silently crash
when a test case changes segments.

This commit fixes this issue by loading KVM-Unit-Tests GDT to replace
UEFI GDT. And since Task State Segment (TSS) is tightly coupled with
GDT, this commit also loads TSS on boot-up.

In this commit, x86/debug.c can run in UEFI and pass all sub-tests.

Co-developed-by: Varad Gautam <varad.gautam@suse.com>
Signed-off-by: Varad Gautam <varad.gautam@suse.com>
Signed-off-by: Zixuan Wang <zixuanwang@google.com>
Message-Id: <20211004204931.1537823-8-zxwang42@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

x86 UEFI: Load IDT after UEFI boot up

Interrupt descriptor table (IDT) is used by x86 arch to describe the
interrupt handlers. UEFI already setup an IDT before running the test
binaries, but this ID

x86 UEFI: Load IDT after UEFI boot up

Interrupt descriptor table (IDT) is used by x86 arch to describe the
interrupt handlers. UEFI already setup an IDT before running the test
binaries, but this IDT is not compatible with the existing
KVM-Unit-Tests test cases, e.g., x86/msr.c triggers a #GP fault when
using UEFI IDT. This is because test cases setup new interrupt handlers
and register them into KVM-Unit-Tests' IDT, but it takes no effect if we
do not load KVM-Unit-Tests' IDT.

This commit fixes this issue by setting up and loding the IDT.

In this commit, the x86/msr.c can run in UEFI and generates same output
as the default Seabios version.

Co-developed-by: Varad Gautam <varad.gautam@suse.com>
Signed-off-by: Varad Gautam <varad.gautam@suse.com>
Signed-off-by: Zixuan Wang <zixuanwang@google.com>
Message-Id: <20211004204931.1537823-7-zxwang42@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

x86 UEFI: Boot from UEFI

This commit provides initial support for x86 test cases to boot from
UEFI:

1. UEFI compiler flags are added to Makefile
2. A new TARGET_EFI macro is added to turn on/

x86 UEFI: Boot from UEFI

This commit provides initial support for x86 test cases to boot from
UEFI:

1. UEFI compiler flags are added to Makefile
2. A new TARGET_EFI macro is added to turn on/off UEFI startup code
3. Previous Multiboot setup code is refactored and updated for
supporting UEFI, including the following changes:
1. x86/efi/crt0-efi-x86_64.S: provides entry point and jumps to
setup code in lib/efi.c.
2. lib/efi.c: performs UEFI setup, calls arch-related setup
functions, then jumps to test case main() function
3. lib/x86/setup.c: provides arch-related setup under UEFI

To build test cases for UEFI, please first install the GNU-EFI library.
Check x86/efi/README.md for more details.

This commit is tested by a simple test calling report() and
report_summayr(). This commit does not include such a test to avoid
unnecessary files added into git history. To build and run this test in
UEFI (assuming file name is x86/dummy.c):

./configure --target-efi
make x86/dummy.efi
./x86/efi/run ./x86/dummy.efi

To use the default Multiboot instead of UEFI:

./configure
make x86/dummy.flat
./x86/run ./x86/dummy.flat

Some x86 test cases require additional fixes to work in UEFI, e.g.,
converting to position independent code (PIC), setting up page tables,
etc. This commit does not provide these fixes, so compiling and running
UEFI test cases other than x86/dummy.c may trigger compiler errors or
QEMU crashes. These test cases will be fixed by the follow-up commits in
this series.

The following code is ported from github.com/rhdrjones/kvm-unit-tests
- ./configure: 'target-efi'-related code

See original code:
- Repo: https://github.com/rhdrjones/kvm-unit-tests
- Branch: target-efi

Co-developed-by: Varad Gautam <varad.gautam@suse.com>
Signed-off-by: Varad Gautam <varad.gautam@suse.com>
Signed-off-by: Zixuan Wang <zixuanwang@google.com>
Message-Id: <20211004204931.1537823-6-zxwang42@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

x86: Move 32-bit GDT and TSS to desc.c

Move the GDT and TSS data structures from x86/cstart.S to
lib/x86/desc.c, for consistency with the 64-bit version.

Signed-off-by: Paolo Bonzini <pbonzini@redh

x86: Move 32-bit GDT and TSS to desc.c

Move the GDT and TSS data structures from x86/cstart.S to
lib/x86/desc.c, for consistency with the 64-bit version.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

x86: Move 64-bit GDT and TSS to desc.c

Move the GDT and TSS data structures from x86/cstart64.S to
lib/x86/desc.c, so that the follow-up UEFI support commits can reuse
these definitions, without re-

x86: Move 64-bit GDT and TSS to desc.c

Move the GDT and TSS data structures from x86/cstart64.S to
lib/x86/desc.c, so that the follow-up UEFI support commits can reuse
these definitions, without re-defining them in UEFI's boot up assembly
code.

Signed-off-by: Zixuan Wang <zixuanwang@google.com>
Message-Id: <20211004204931.1537823-2-zxwang42@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

x86: Allow to limit maximum RAM address

While there is a feature to limit RAM memory, we should also be able to
limit the maximum RAM address. Specifically, svm can only work when the
maximum RAM ad

x86: Allow to limit maximum RAM address

While there is a feature to limit RAM memory, we should also be able to
limit the maximum RAM address. Specifically, svm can only work when the
maximum RAM address is lower than 4G, as it does not map the rest of the
memory into the NPT.

Allow to do so using the firmware, when in fact the expected use-case is
to provide this infomation on bare-metal using the MEMLIMIT parameter in
initrd.

Signed-off-by: Nadav Amit <namit@vmware.com>
Message-Id: <20200710183320.27266-5-namit@vmware.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

x86: allow using memory above 4 GiB

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

x86: Support environments without test-devices

Enable to run the tests when test-device is not present (e.g.,
bare-metal). Users can provide the number of CPUs and ram size through
kernel parameters

x86: Support environments without test-devices

Enable to run the tests when test-device is not present (e.g.,
bare-metal). Users can provide the number of CPUs and ram size through
kernel parameters.

On Ubuntu that uses grub, for example, the tests can be run by copying a
test to the boot directory (/boot) and adding a menu-entry to grub
(e.g., by editing /etc/grub.d/40_custom):

menuentry 'idt_test' {
set root='[ROOT]'
multiboot [BOOT_RELATIVE]/[TEST].flat [PARAMETERS]
module params.initrd
}

Replace:
* [ROOT] with `grub-probe --target=bios_hints /boot`
* [BOOT_RELATIVE] with `grub-mkrelpath /boot`
* [TEST] with the test executed
* [PARAMETERS] with the test parameters

params.initrd, which would be located on the boot directory should
describe the machine and tell the test infrastructure that a test
device is not present and boot-loader was used (the bootloader and qemu
deliver test . For example for a 4 core machines with 4GB of
memory:

NR_CPUS=4
MEMSIZE=4096
TEST_DEVICE=0
BOOTLOADER=1

Since we do not really use E820, using more than 4GB is likely to fail
due to holes.

Finally, do not forget to run update-grub. Remember that the output goes
to the serial port.

Cc: Andrew Jones <drjones@redhat.com>
Signed-off-by: Nadav Amit <nadav.amit@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

x86: Add missing prototypes and mark more local functions as static

To be able to compile with -Wmissing-prototypes, we also need prototypes
for functions that are called from assembler code. We put

x86: Add missing prototypes and mark more local functions as static

To be able to compile with -Wmissing-prototypes, we also need prototypes
for functions that are called from assembler code. We put the prototypes
into the .c files and not into header files here, since these functions
are not called from other .c files.
While we're at it, also mark some more functions as static in these
files which are only used locally.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1538123582-17442-3-git-send-email-thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

x86: setup: fixes to alloc_phys setup

There were two thinkos in commit 937e239 ("x86: use alloc_phys",
2017-11-02).

First, alloc_phys is not initialized if there are no multiboot modules,
as is the

x86: setup: fixes to alloc_phys setup

There were two thinkos in commit 937e239 ("x86: use alloc_phys",
2017-11-02).

First, alloc_phys is not initialized if there are no multiboot modules,
as is the case when invoking QEMU directly with a test kernel.

Second, one "&" was missing, so the topmost memory address was passed
as the size to phys_alloc_init.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

x86: use alloc_phys

As the next step in making vmalloc/vfree available to every other architecture,
register the available memory with phys_alloc for x86 too, and add a service
to return the unused

x86: use alloc_phys

As the next step in making vmalloc/vfree available to every other architecture,
register the available memory with phys_alloc for x86 too, and add a service
to return the unused phys_alloc region. This makes setup_vm architecture-
independent.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

x86: prepare for extending setup.c

Rename setup_get_initrd to setup_multiboot as we will get memory map
information from there, and since we are at it setup_environ to
setup_libcflat.

Use C structs

x86: prepare for extending setup.c

Rename setup_get_initrd to setup_multiboot as we will get memory map
information from there, and since we are at it setup_environ to
setup_libcflat.

Use C structs for multiboot information instead of offsets.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

x86: enable environ

Give x86 unit tests access to environment variables. The
environment variables are passed to the unit test with
'-initrd env-file'.

Signed-off-by: Andrew Jones <drjones@redhat.c

x86: enable environ

Give x86 unit tests access to environment variables. The
environment variables are passed to the unit test with
'-initrd env-file'.

Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>

show more ...

x86: import initrd

If an initrd is provided on the qemu command line, then set a
pointer to it during setup.

Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@re

x86: import initrd

If an initrd is provided on the qemu command line, then set a
pointer to it during setup.

Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>

show more ...