Re: [Xen-devel] [RFC] xen/pvh: detect PVH after kexec

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 21/03/17 10:42, Jan Beulich wrote:
>>>> On 21.03.17 at 11:21, <roger.pau@xxxxxxxxxx> wrote:
>> On Tue, Mar 21, 2017 at 04:07:51AM -0600, Jan Beulich wrote:
>>>>>> On 21.03.17 at 11:01, <roger.pau@xxxxxxxxxx> wrote:
>>>> On Tue, Mar 21, 2017 at 10:21:52AM +0100, Vitaly Kuznetsov wrote:
>>>>> Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> writes:
>>>>>
>>>>>> On 03/20/2017 02:20 PM, Vitaly Kuznetsov wrote:
>>>>>>> PVH guests after kexec boot like normal HVM guests and we're not 
>>>>>>> entering
>>>>>>> xen_prepare_pvh()
>>>>>> Is it not? Aren't we going via xen_hvm_shutdown() and then
>>>>>> SHUTDOWN_soft_reset which would restart at the same entry point as
>>>>>> regular boot?
>>>>> No, we're not doing regular boot: from outside of the guest we don't
>>>>> really know where the new kernel is placed (as guest does it on its
>>>>> own). We do soft reset to clean things up and then guest jumps to the
>>>>> new kernel starting point by itself.
>>>>>
>>>>> We could (in theory, didn't try) make it jump to the PVH starting point
>>>>> but we'll have to at least prepare the right boot params for
>>>>> init_pvh_bootparams and this looks like additional
>>>>> complication. PVHVM-style startup suits us well but we still need to be
>>>>> PVH-aware.
>>>> We are going to have the same issue when booting PVH with OVMF, Linux will 
>> be
>>>> started at the native UEFI entry point, and we will need some way to detect
>>>> that we are running in PVH mode.
>>> I'm confused: PVH boots without any firmware, doesn't it? Hence
>>> it shouldn't matter if there's no (legacy) BIOS or no OVMF ...
>> Right now yes, we have no firmware available to PVH at all, but Anthony is
>> already working on porting OVMF to PVH [0].
> But that leaves open the "why" aspect: What use is OVMF to a
> PVH guest?

1) To work around the massive security attack surface of PV guests.
2) Because we think we can boot windows without Qemu in this way.

With my XenServer hat on, this is an absolute must.  I want to be
loading a single hvmloader-like-thing (pvhloader?) from dom0, which can
then chainload the guests preferred bootloader, parse filesystems and
kernels, all in guest context rather than dom0 context.

This also means that when the guest switches to a new filesystem, or
linux change their compression, no dom0 modifications are required.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel