Re: [Xen-devel] Xen PVH support in grub2

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 11/06/2017 10:05 AM, Juergen Gross wrote:
> On 06/11/17 15:51, Boris Ostrovsky wrote:
>> On 11/06/2017 02:16 AM, Juergen Gross wrote:
>>> On 03/11/17 20:00, Boris Ostrovsky wrote:
>>>> On 11/03/2017 02:40 PM, Juergen Gross wrote:
>>>>> On 03/11/17 19:35, Boris Ostrovsky wrote:
>>>>>> On 11/03/2017 02:23 PM, Juergen Gross wrote:
>>>>>>> On 03/11/17 19:19, Boris Ostrovsky wrote:
>>>>>>>> On 11/03/2017 02:05 PM, Juergen Gross wrote:
>>>>>>>>> So again the question: how to tell whether we are PVH or HVM in
>>>>>>>>> init_hypervisor_platform()? ACPi tables are scanned way later...
>>>>>>>> Can we make grub/OVMF append a boot option?
>>>>>>>>
>>>>>>>> Or set setup_header.hardware_subarch to something? We already have
>>>>>>>> X86_SUBARCH_XEN but it is only used by PV.  Or we might be able to use
>>>>>>>> hardware_subarch_data (will need to get a buy-in from x86 maintainers, 
>>>>>>>> I
>>>>>>>> think).
>>>>>>> But wouldn't this break the idea to reuse the native boot paths in
>>>>>>> grub/OVMF without further modifications?
>>>>>> WDYM? We will have to have some sort of a plugin in either one to build
>>>>>> the zeropage anyway. So we'd set hardware_subarch there, in addition to
>>>>>> other things like setting memory and such.
>>>>> But isn't the zeropage already being built? I admit that setting subarch
>>>>> isn't a big deal, but using another entry with a passed-through pvh
>>>>> start struct isn't either...
>>>> I don't follow, sorry. My understanding is that zeropage will be built
>>>> by PVH-enlightened grub so part of this process would be setting the
>>>> subarch bit.
>>> My reasoning was based on Roger's remark:
>>>
>>> "OTOH if Linux is capable of booting from the native entry point inside
>>> of a PVH container, we would only have to port OVMF and grub in order
>>> to work inside of a PVH container, leaving the rest of the logic
>>> untouched."
>> Right, and in my mind porting OVMF/grub includes creating proper zeropage.
> Aah, okay. I reasoned on the assumption to just enable OVMF/grub to run
> in PVH environment without touching the parts setting up anything for
> the new kernel.

Someone needs to do what xen_prepare_pvh() does.

And, for 64-bit, we also may need to build early pagetables since
startup_64() (unlike startup_32()) expects paging to be on. (I don't
know whether this is already part of standard FW codepath)

>
>> BTW, another option might be to "type_of_loader = (9 << 4) | 0", which
>> is what init_pvh_bootparams() does. In fact, whatever is done in the
>> firmware should probably match what that routine does.
> So it wouldn't be possible any longer to tell whether the kernel has
> been booted directly or via grub. I don't like this. The loader type
> is accessible via sysfs after all.

I didn't know that. What is the path?

-boris


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