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

[Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>]

Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> writes:

> On 03/21/2017 08:13 AM, Roger Pau Monne wrote:
>> On Tue, Mar 21, 2017 at 12:53:07PM +0100, Vitaly Kuznetsov wrote:
>>> Roger Pau Monne <roger.pau@xxxxxxxxxx> writes:
>>>
>>>> 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.
>>>>
>>>> What issues do you see when using the HVM boot path for kexec?
>>> The immediate issue I ran into was ballooning driver over-allocating
>>> with XENMEM_populate_physmap:
>
> I couldn't go even that far. Is there anything besides the two libxl
> patches that you posted yesterday?
>

No, the two patches should be enough. I only tested kdump so far.


-- 
  Vitaly

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