Commit graph

3 commits

Author SHA1 Message Date
Joe Richey 770275ed0c optionrom/pvh: scan entire RSDP Area
Right now the PVH option rom scans for the RSDP from 0xE0000 to
0xE1FFF. This is probobly a typo, it should scan from 0xE0000 to
0xFFFFF.

This is actually an issue on some QEMU versions/machines. For example,
when I run QEMU the RSDP is placed at 0xf5ad0 which will not be picked
up by the current implementation.

This bug still allows a Linux guest to boot (in most configurations) as
the kernel will just scan for the RSDP if one isn't provided.

Signed-off-by: Joe Richey <joerichey@google.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Fixes: 2785dc7b17 ("optionrom: add new PVH option rom")
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16 22:07:42 +01:00
Stefano Garzarella b1b876ca70 optionrom/pvh: load initrd from fw_cfg
If we found initrd through fw_cfg, we can load it and use the
first module of hvm_start_info to pass initrd address and size
to the kernel.

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
Based-on: <1547554687-12687-1-git-send-email-liam.merwick@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-05 16:50:17 +01:00
Stefano Garzarella 2785dc7b17 optionrom: add new PVH option rom
The new pvh.bin option rom can be used with SeaBIOS to boot
uncompressed kernel using the x86/HVM direct boot ABI.

pvh.S contains the entry point of the option rom. It runs
in real mode, loads the e820 table querying the BIOS, and
then it switches to 32bit protected mode and jumps to the
pvh_load_kernel() written in pvh_main.c.
pvh_load_kernel() loads the cmdline and kernel entry_point
using fw_cfg, then it looks for RSDP, fills the
hvm_start_info required by x86/HVM ABI, and finally jumps
to the kernel entry_point.

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
2019-02-05 16:50:17 +01:00