From: Paolo Bonzini <pbonzini@redhat.com>
To: Juergen Gross <jgross@suse.com>,
Maran Wilson <maran.wilson@oracle.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
xen-devel@lists.xenproject.org, kvm@vger.kernel.org
Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
boris.ostrovsky@oracle.com, jpoimboe@redhat.com,
kirill.shutemov@linux.intel.com, bp@suse.de,
thomas.lendacky@amd.com, luto@kernel.org,
dave.hansen@linux.intel.com, roger.pau@citrix.com,
rkrcmar@redhat.com, rdunlap@infradead.org
Subject: Re: [PATCH v8 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH
Date: Fri, 7 Dec 2018 16:14:15 +0100 [thread overview]
Message-ID: <d18b961a-d115-8d12-8ee4-eb1a3466959c@redhat.com> (raw)
In-Reply-To: <5d1d0071-1db4-ea03-027f-2a12812b78d0@suse.com>
On 07/12/18 14:58, Juergen Gross wrote:
> 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.
Aha - for KVM, the main advantage of PVH would be to skip the cost of
decompression, and that is what confused me (also we probably prefer not
having any decompression code running in QEMU, since that increases the
attack surface; there's no real disadvantage to using the existing
linuxboot code if we're given a bzImage). So, at least for now, KVM
would go with the two-binaries/one-config approach.
Sorry for having you lecture me, it's much clearer now. Thanks,
Paolo
next prev parent reply other threads:[~2018-12-07 15:14 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-06 6:02 [PATCH v8 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point Maran Wilson
2018-12-06 6:04 ` [PATCH v8 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH Maran Wilson
2018-12-06 22:11 ` Paolo Bonzini
2018-12-06 22:34 ` Boris Ostrovsky
2018-12-06 22:49 ` Paolo Bonzini
2018-12-06 23:11 ` Boris Ostrovsky
2018-12-06 23:30 ` Paolo Bonzini
2018-12-06 23:36 ` [Xen-devel] " Andrew Cooper
2018-12-07 6:02 ` Juergen Gross
2018-12-07 13:41 ` Paolo Bonzini
2018-12-07 13:50 ` Juergen Gross
2018-12-07 13:52 ` Paolo Bonzini
2018-12-07 13:58 ` Juergen Gross
2018-12-07 15:14 ` Paolo Bonzini [this message]
2018-12-07 18:21 ` Maran Wilson
2018-12-06 6:04 ` [PATCH v8 2/7] xen/pvh: Move PVH entry code out of Xen specific tree Maran Wilson
2018-12-06 6:05 ` [PATCH v8 3/7] xen/pvh: Create a new file for Xen specific PVH code Maran Wilson
2018-12-06 6:05 ` [PATCH v8 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common file Maran Wilson
2018-12-06 6:05 ` [PATCH v8 5/7] xen/pvh: Move Xen code for getting mem map via hcall " Maran Wilson
2018-12-06 6:06 ` [PATCH v8 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct Maran Wilson
2018-12-06 6:06 ` [PATCH v8 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point Maran Wilson
2018-12-06 22:05 ` Paolo Bonzini
2018-12-06 21:21 ` [PATCH v8 0/7] " Paolo Bonzini
2018-12-06 21:37 ` Borislav Petkov
2018-12-06 21:58 ` Boris Ostrovsky
2018-12-06 22:14 ` Paolo Bonzini
2018-12-07 10:25 ` Borislav Petkov
2018-12-07 16:07 ` [Xen-devel] " Boris Ostrovsky
2018-12-07 19:22 ` Borislav Petkov
2018-12-12 18:09 ` Maran Wilson
2018-12-12 18:17 ` Boris Ostrovsky
2018-12-13 13:13 ` Paolo Bonzini
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=d18b961a-d115-8d12-8ee4-eb1a3466959c@redhat.com \
--to=pbonzini@redhat.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@suse.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=jpoimboe@redhat.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=maran.wilson@oracle.com \
--cc=mingo@redhat.com \
--cc=rdunlap@infradead.org \
--cc=rkrcmar@redhat.com \
--cc=roger.pau@citrix.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
--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).