[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5d1d0071-1db4-ea03-027f-2a12812b78d0@suse.com>
Date: Fri, 7 Dec 2018 14:58:48 +0100
From: Juergen Gross <jgross@...e.com>
To: Paolo Bonzini <pbonzini@...hat.com>,
Maran Wilson <maran.wilson@...cle.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, xen-devel@...ts.xenproject.org,
kvm@...r.kernel.org
Cc: tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
boris.ostrovsky@...cle.com, jpoimboe@...hat.com,
kirill.shutemov@...ux.intel.com, bp@...e.de,
thomas.lendacky@....com, luto@...nel.org,
dave.hansen@...ux.intel.com, roger.pau@...rix.com,
rkrcmar@...hat.com, rdunlap@...radead.org
Subject: Re: [PATCH v8 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and
CONFIG_XEN_PVH
On 07/12/2018 14:52, Paolo Bonzini wrote:
> On 07/12/18 14:50, Juergen Gross wrote:
>> The PVH boot entry is in the same bzImage binary as the normal one.
>> Its just another entry, similar to the Xen PV boot entry. So the binary
>> arch/x86/boot/bzimage can be booted either on bare metal via grub2 or
>> other boot-loaders, as Xen PV-guest, as Xen PVH-guest, or as KVM
>> PVH-guest. So one build and one binary. The non-standard boot entries
>> (PV- or PVH-node) are found via ELF-notes by the boot loader (qemu in
>> case of KVM).
>>
>
> But the bzImage is not an ELF binary, and it is compressed, isn't it?
> /me is confused. :)
grub2 (and qemu, too) can decompress it. And the decompressed result
"vmlinux" is an ELF-binary.
Juergen
Powered by blists - more mailing lists