Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v8 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and
 CONFIG_XEN_PVH
To:     Paolo Bonzini <pbonzini@redhat.com>,
        Juergen Gross <jgross@suse.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
References: <1544076152-21637-1-git-send-email-maran.wilson@oracle.com>
 <1544076257-21792-1-git-send-email-maran.wilson@oracle.com>
 <d532f023-85f9-62b9-ca56-53a619fdcd1e@redhat.com>
 <2c289956-0e6a-700c-605d-83685fbb08f9@suse.com>
 <0a2f692a-f7df-8ad1-9d34-96f5e36926db@redhat.com>
 <3f95d053-87aa-ad45-03e6-1e1977283eb4@suse.com>
 <d0fd8799-35ea-fba5-9d0d-94feead85943@redhat.com>
 <5d1d0071-1db4-ea03-027f-2a12812b78d0@suse.com>
 <d18b961a-d115-8d12-8ee4-eb1a3466959c@redhat.com>
From:   Maran Wilson <maran.wilson@oracle.com>
Organization: Oracle Corporation
Message-ID: <6f71c714-1a72-1619-fd1f-f5d1044ce217@oracle.com>
Date:   Fri, 7 Dec 2018 10:21:59 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.3.2
MIME-Version: 1.0
In-Reply-To: <d18b961a-d115-8d12-8ee4-eb1a3466959c@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 12/7/2018 7:14 AM, Paolo Bonzini wrote:
> 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.

Yeah, the way we have been testing with the Qemu/qboot changes that Liam 
has out for review, if you provide the bzImage binary in the -kernel 
argument, legacy behavior is followed. However if you provide the 
vmlinux binary (from the same kernel build), Qemu recognizes it as an 
ELF binary, looks for the presence of the PVH ELFNOTE, and (if the 
ELFNOTE in question is found) uses that entry point instead.

So at this point, the only feedback/comment still outstanding from you 
is the one about removing KVM_GUEST_PVH right?

I'll hold off on sending a v9 until next week to see if there is any 
additional feedback or test results.

Thanks,
-Maran

> Sorry for having you lecture me, it's much clearer now.  Thanks,
>
> Paolo