xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Maran Wilson <maran.wilson@oracle.com>
To: Stefano Garzarella <sgarzare@redhat.com>, liam.merwick@oracle.com
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	mst@redhat.com, qemu-devel@nongnu.org,
	Stefan Hajnoczi <stefanha@redhat.com>,
	xen-devel@lists.xenproject.org,
	Paolo Bonzini <pbonzini@redhat.com>,
	rth@twiddle.net
Subject: Re: [RFC 3/3] pvh: Boot uncompressed kernel using direct boot ABI
Date: Tue, 11 Dec 2018 10:35:01 -0800	[thread overview]
Message-ID: <33fb9ea4-d6c5-ed23-2fb5-6f818e250043@oracle.com> (raw)
In-Reply-To: <CAGxU2F4j11wVoDktowJwXDy42_PWbjwF0qAueFg+He4Tb86wgQ@mail.gmail.com>

On 12/11/2018 9:11 AM, Stefano Garzarella wrote:
> Hi Liam,
> in order to support PVH also with SeaBIOS, I'm going to work on a new
> option rom (like linuxboot/multiboot) that can be used in this case.

That is awesome. Yes, please keep us posted when you have something working.

Just FYI, before switching over to using Qemu+qboot, we had been using a 
Qemu only solution (but not using an option rom) internally that worked 
very well using no FW at all. We had Qemu simply parse the ELF file and 
jump to the PVH entry point if one is found. The only gotcha was that we 
had to include a pair of patches that were originally written by folks 
at Intel as part of the clear containers work. Specifically, in order to 
be able to skip firmware entirely, we had to do 2 additional things: (1) 
ACPI tables generated by Qemu are usually patched up by FW. Since we 
were running no FW, we needed to do that patching up of the ACPI tables 
in Qemu when it was detected that we were going to enter the OS via the 
PVH entry point. (2) We also needed to add a patch to Qemu to enable a 
few PM registers -- something typically done by FW.

But if SeaBIOS is involved in the solution you are working on, I guess 
you won't really need those extra patches. Just figured I'd mention it 
so you have the full picture.

Thanks,
-Maran

> I'll keep you updated on it!
>
> Cheers,
> Stefano
> On Wed, Dec 5, 2018 at 11:38 PM Liam Merwick <liam.merwick@oracle.com> wrote:
>> These changes (along with corresponding qboot and Linux kernel changes)
>> enable a guest to be booted using the x86/HVM direct boot ABI.
>>
>> This commit adds a load_elfboot() routine to pass the size and
>> location of the kernel entry point to qboot (which will fill in
>> the start_info struct information needed to to boot the guest).
>> Having loaded the ELF binary, load_linux() will run qboot
>> which continues the boot.
>>
>> The address for the kernel entry point has already been read
>> from an ELF Note in the uncompressed kernel binary earlier
>> in pc_memory_init().
>>
>> Signed-off-by: George Kennedy <George.Kennedy@oracle.com>
>> Signed-off-by: Liam Merwick <Liam.Merwick@oracle.com>
>> ---
>>   hw/i386/pc.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 72 insertions(+)
>>
>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>> index 056aa46d99b9..d3012cbd8597 100644
>> --- a/hw/i386/pc.c
>> +++ b/hw/i386/pc.c
>> @@ -54,6 +54,7 @@
>>   #include "sysemu/qtest.h"
>>   #include "kvm_i386.h"
>>   #include "hw/xen/xen.h"
>> +#include "hw/xen/start_info.h"
>>   #include "ui/qemu-spice.h"
>>   #include "exec/memory.h"
>>   #include "exec/address-spaces.h"
>> @@ -1098,6 +1099,50 @@ done:
>>       return pvh_start_addr != 0;
>>   }
>>
>> +static bool load_elfboot(const char *kernel_filename,
>> +                   int kernel_file_size,
>> +                   uint8_t *header,
>> +                   size_t pvh_xen_start_addr,
>> +                   FWCfgState *fw_cfg)
>> +{
>> +    uint32_t flags = 0;
>> +    uint32_t mh_load_addr = 0;
>> +    uint32_t elf_kernel_size = 0;
>> +    uint64_t elf_entry;
>> +    uint64_t elf_low, elf_high;
>> +    int kernel_size;
>> +
>> +    if (ldl_p(header) != 0x464c457f) {
>> +        return false; /* no elfboot */
>> +    }
>> +
>> +    bool elf_is64 = header[EI_CLASS] == ELFCLASS64;
>> +    flags = elf_is64 ?
>> +        ((Elf64_Ehdr *)header)->e_flags : ((Elf32_Ehdr *)header)->e_flags;
>> +
>> +    if (flags & 0x00010004) { /* LOAD_ELF_HEADER_HAS_ADDR */
>> +        error_report("elfboot unsupported flags = %x", flags);
>> +        exit(1);
>> +    }
>> +
>> +    kernel_size = load_elf(kernel_filename, NULL, NULL, &elf_entry,
>> +                           &elf_low, &elf_high, 0, I386_ELF_MACHINE,
>> +                           0, 0);
>> +
>> +    if (kernel_size < 0) {
>> +        error_report("Error while loading elf kernel");
>> +        exit(1);
>> +    }
>> +    mh_load_addr = elf_low;
>> +    elf_kernel_size = elf_high - elf_low;
>> +
>> +    fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_ENTRY, pvh_xen_start_addr);
>> +    fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_ADDR, mh_load_addr);
>> +    fw_cfg_add_i32(fw_cfg, FW_CFG_KERNEL_SIZE, elf_kernel_size);
>> +
>> +    return true;
>> +}
>> +
>>   static void load_linux(PCMachineState *pcms,
>>                          FWCfgState *fw_cfg)
>>   {
>> @@ -1138,6 +1183,33 @@ static void load_linux(PCMachineState *pcms,
>>       if (ldl_p(header+0x202) == 0x53726448) {
>>           protocol = lduw_p(header+0x206);
>>       } else {
>> +        /* If the kernel address for using the x86/HVM direct boot ABI has
>> +         * been saved then proceed with booting the uncompressed kernel */
>> +        if (pvh_start_addr) {
>> +            if (load_elfboot(kernel_filename, kernel_size,
>> +                             header, pvh_start_addr, fw_cfg)) {
>> +                struct hvm_modlist_entry ramdisk_mod = { 0 };
>> +
>> +                fclose(f);
>> +
>> +                fw_cfg_add_i32(fw_cfg, FW_CFG_CMDLINE_SIZE,
>> +                    strlen(kernel_cmdline) + 1);
>> +                fw_cfg_add_string(fw_cfg, FW_CFG_CMDLINE_DATA, kernel_cmdline);
>> +
>> +                assert(machine->device_memory != NULL);
>> +                ramdisk_mod.paddr = machine->device_memory->base;
>> +                ramdisk_mod.size =
>> +                    memory_region_size(&machine->device_memory->mr);
>> +
>> +                fw_cfg_add_bytes(fw_cfg, FW_CFG_KERNEL_DATA, &ramdisk_mod,
>> +                                 sizeof(ramdisk_mod));
>> +                fw_cfg_add_i32(fw_cfg, FW_CFG_SETUP_SIZE, sizeof(header));
>> +                fw_cfg_add_bytes(fw_cfg, FW_CFG_SETUP_DATA,
>> +                                 header, sizeof(header));
>> +
>> +                return;
>> +            }
>> +        }
>>           /* This looks like a multiboot kernel. If it is, let's stop
>>              treating it like a Linux kernel. */
>>           if (load_multiboot(fw_cfg, f, kernel_filename, initrd_filename,
>> --
>> 1.8.3.1
>>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  parent reply	other threads:[~2018-12-11 18:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-05 22:37 [RFC 0/3] QEMU changes to do PVH boot Liam Merwick
2018-12-05 22:37 ` [RFC 1/3] pvh: Add x86/HVM direct boot ABI header file Liam Merwick
2018-12-11 14:01   ` Stefan Hajnoczi
2018-12-11 14:57     ` Liam Merwick
2018-12-11 15:03       ` [Qemu-devel] " Daniel P. Berrangé
2018-12-21 20:03       ` Liam Merwick
2018-12-05 22:37 ` [RFC 2/3] pc: Read PVH entry point from ELF note in kernel binary Liam Merwick
2018-12-11 14:17   ` Stefan Hajnoczi
     [not found]   ` <20181211141732.GB23460@stefanha-x1.localdomain>
2018-12-21 20:03     ` Liam Merwick
2018-12-05 22:37 ` [RFC 3/3] pvh: Boot uncompressed kernel using direct boot ABI Liam Merwick
2018-12-11 17:11   ` Stefano Garzarella
     [not found]   ` <CAGxU2F4j11wVoDktowJwXDy42_PWbjwF0qAueFg+He4Tb86wgQ@mail.gmail.com>
2018-12-11 18:35     ` Maran Wilson [this message]
2018-12-12 15:28       ` Stefano Garzarella
     [not found]       ` <CAGxU2F793nfiFADnJW-j-vLSS0Mp-XP54JFEq++0_JunHQj50w@mail.gmail.com>
2018-12-12 17:36         ` Maran Wilson
2018-12-06  0:01 ` [Qemu-devel] [RFC 0/3] QEMU changes to do PVH boot no-reply
2018-12-06  6:18 ` Maran Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=33fb9ea4-d6c5-ed23-2fb5-6f818e250043@oracle.com \
    --to=maran.wilson@oracle.com \
    --cc=ehabkost@redhat.com \
    --cc=liam.merwick@oracle.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).