lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 29 Nov 2017 09:25:50 -0500
From:   Boris Ostrovsky <>
To:     Roger Pau Monné <>,
        Juergen Gross <>
Cc:     Maran Wilson <>,,,,,,,,,,,
Subject: Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

On 11/29/2017 09:18 AM, Roger Pau Monné wrote:
> On Wed, Nov 29, 2017 at 03:11:12PM +0100, Juergen Gross wrote:
>> On 29/11/17 15:03, Boris Ostrovsky wrote:
>>> On 11/29/2017 03:50 AM, Roger Pau Monné wrote:
>>>> On Wed, Nov 29, 2017 at 09:21:59AM +0100, Juergen Gross wrote:
>>>>> On 28/11/17 20:34, 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:
>>>> I would also add a link to:
>>>>>> This PoC patch enables Qemu to use that same entry point for booting KVM
>>>>>> guests.
>>>>>> Even though the code is still PoC quality, I'm sending this as an RFC now
>>>>>> since there are a number of different ways the specific implementation
>>>>>> details can be handled. I chose a shared code path for Xen and KVM guests
>>>>>> but could just as easily create a separate code path that is advertised by
>>>>>> a different ELF note for KVM. There also seems to be some flexibility in
>>>>>> how the e820 table data is passed and how (or if) it should be identified
>>>>>> as e820 data. As a starting point, I've chosen the options that seem to
>>>>>> result in the smallest patch with minimal to no changes required of the
>>>>>> x86/HVM direct boot ABI.
>>>>> I like the idea.
>>>>> I'd rather split up the different hypervisor types early and use a
>>>>> common set of service functions instead of special casing xen_guest
>>>>> everywhere. This would make it much easier to support the KVM PVH
>>>>> boot without the need to configure the kernel with CONFIG_XEN.
>>>>> Another option would be to use the same boot path as with grub: set
>>>>> the boot params in zeropage and start at startup_32.
>>>> I think I prefer this approach since AFAICT it should allow for
>>>> greater code share with the common boot path.
>>> zeropage is x86/Linux-specific so we'd need some sort of firmware (like
>>> grub) between a hypervisor and Linux to convert hvm_start_info to
>>> bootparams.
>> qemu?

I think KVM folks didn't want to do this. I can't find the thread but I
believe it was somewhere during Clear Containers discussion. Paolo?

> But then it won't be using the PVH entry point, and would just use the
> native one?
> My understanding was that the PVH shim inside of Linux will prepare a
> zero-page when booted using the PVH entry point, and then jump into
> the native boot path.

Right, but that's not what Juergen's second option is. IIUIC with that
option Linux starts with zeropage already prepared. No shim in the kernel.


Powered by blists - more mailing lists