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

[Juergen Gross <jgross@xxxxxxxx>]

On 06/11/17 17:42, Boris Ostrovsky wrote:
> 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.

As the loader is filling in the memory map information the only thing
remaining would be setting xen_pvh. And this could be delayed as my test
have shown, so we only need to detect the PVH case from inside the
kernel. One possibility would be the flags in the ACPI FADT table as
Roger mentioned, another idea would be a flag in zeropage set by the
loader.

> 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)

This would be done the same way as for a native kernel.

>>> 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?

/proc/sys/kernel/bootloader_type


Juergen


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