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 v9 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point
To:     Borislav Petkov <bp@alien8.de>
Cc:     x86@kernel.org, xen-devel@lists.xenproject.org,
        linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        pbonzini@redhat.com, jgross@suse.com, boris.ostrovsky@oracle.com,
        bp@suse.de, dave.hansen@linux.intel.com, davem@davemloft.net,
        gregkh@linuxfoundation.org, hpa@zytor.com, jpoimboe@redhat.com,
        kirill.shutemov@linux.intel.com, luto@kernel.org,
        mchehab@kernel.org, mingo@redhat.com, rdunlap@infradead.org,
        tglx@linutronix.de, thomas.lendacky@amd.com, hch@infradead.org,
        roger.pau@citrix.com, rkrcmar@redhat.com
References: <1544468734-32763-1-git-send-email-maran.wilson@oracle.com>
 <20181211131825.GD27375@zn.tnic>
From:   Maran Wilson <maran.wilson@oracle.com>
Organization: Oracle Corporation
Message-ID: <5fc083d4-1dbd-f2f9-3059-0e3e8dda9b25@oracle.com>
Date:   Tue, 11 Dec 2018 11:29:21 -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: <20181211131825.GD27375@zn.tnic>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 12/11/2018 5:18 AM, Borislav Petkov wrote:
> On Mon, Dec 10, 2018 at 11:05:34AM -0800, Maran Wilson wrote:
>> For certain applications it is desirable to rapidly boot a KVM virtual
>> machine. In cases where legacy hardware and software support within the
>> guest is not needed, Qemu should be able to boot directly into the
>> uncompressed Linux kernel binary without the need to run firmware.
>>
>> There already exists an ABI to allow this for Xen PVH guests and the ABI
>> is supported by Linux and FreeBSD:
>>
>>     https://xenbits.xen.org/docs/unstable/misc/pvh.html
>>
>> This patch series would enable Qemu to use that same entry point for
>> booting KVM guests.
> How would I do that, practically?
>
> Looking at those here:
>
>>   * Qemu and qboot RFC patches have been posted to show one example of how
>>     this functionality can be used. Some preliminary numbers are available
>>     in those cover letters showing the KVM guest boot time improvement.
>>        Qemu:
>>        http://lists.nongnu.org/archive/html/qemu-devel/2018-12/msg00957.html
>>        qboot:
>>        http://lists.nongnu.org/archive/html/qemu-devel/2018-12/msg00953.html
> I might still need to do some dancing to get stuff going.

Is your question about what options you need to provide to Qemu? Or is 
your question about the SW implementation choices?

Assuming the former... once you have compiled all 3 new binaries 
(kernel, Qemu, and qboot) then you simply invoke qemu the same way you 
normally invoke qemu with qboot + kernel binary, except you provide the 
vmlinux (uncompressed) kernel binary when specifying the "-kernel" 
parameter. Qemu/qboot will automatically detect that you have provided 
an ELF binary, find the PVH ELF note to locate the entry point, and 
proceed to boot the kernel via that method. On the other hand, if you 
leave all the Qemu options as-is, but simply provide the bzImage 
(compressed) kernel binary from the same build, Qemu/qboot will boot the 
way it has always done and not look for PVH.

To make it more concrete, here's an example of how I had been invoking 
PVH boot recently:

    x86_64-softmmu/qemu-system-x86_64 \
      -name testvm01 \
      -machine q35,accel=kvm,nvdimm \
      -cpu host \
      -m 1024,maxmem=20G,slots=2 \
      -smp 1 \
      -nodefaults \
      -kernel binaries/vmlinux \
      -object 
memory-backend-file,id=mem0,share,mem-path=binaries/containers.img,size=235929600 
\
      -device nvdimm,memdev=mem0,id=nv0 \
      -append 'console=ttyS0,115200,8n1 root=/dev/pmem0p1 panic=1 rw 
init=/usr/lib/systemd/systemd rootfstype=ext4' \
      -bios binaries/bios.bin \
      -serial mon:stdio

Thanks,
-Maran


> Thx.
>