grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Juergen Gross
Subject: Re: [Xen-devel] Xen PVH support in grub2
Date: Fri, 3 Nov 2017 15:24:45 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 03/11/17 15:07, Roger Pau Monné wrote:
> On Fri, Nov 03, 2017 at 01:50:11PM +0100, Juergen Gross wrote:
>> On 03/11/17 13:17, Roger Pau Monné wrote:
>>> On Fri, Nov 03, 2017 at 01:00:46PM +0100, Juergen Gross wrote:
>>>> On 29/09/17 17:51, Roger Pau Monné wrote:
>>>>> On Fri, Sep 29, 2017 at 03:33:58PM +0000, Juergen Gross wrote:
>>>>>> On 29/09/17 17:24, Roger Pau Monné wrote:
>>>>>>> On Fri, Sep 29, 2017 at 02:46:53PM +0000, Juergen Gross wrote:
>>>>>>> Then, I also wonder whether it would make sense for this grub to load
>>>>>>> the kernel using the PVH entry point or the native entry point. Would
>>>>>>> it be possible to boot a Linux kernel up to the point where cpuid can
>>>>>>> be used inside of a PVH container?
>>>>>>
>>>>>> I don't think today's Linux allows that. This has been discussed
>>>>>> very thoroughly at the time Boris added PVH V2 support to the kernel.
>>>>>
>>>>> OK, I'm not going to insist on that, but my plans for FreeBSD is to
>>>>> make the native entry point capable of booting inside of a PVH
>>>>> container up to the point where cpuid (or whatever method) can be used
>>>>> to detect the environment.
>>>>
>>>> Looking more thoroughly into the Linux boot code I think this could
>>>> work for Linux, too. But only if we can tell PVH from HVM in the guest.
>>>> How would you do that in FreeBSD? Via flags in the boot params? This
>>>> would the have to be done in the boot loader (e.g. grub or OVMF).
>>>
>>> My plan was not to differentiate between HVM and PVH, but rather to
>>> make use of the ACPI information in order to decide which devices are
>>> available and which are not inside of a PVH guest.
>>>
>>> For example in the FADT "IA-PC Boot Architecture Flags" field for PVH
>>> we already set "VGA Not Present" and "CMOS RTC Not Present". There
>>> might be other flags/fields that must be set, but I would like to
>>> avoid having a CPUID bit or similar saying "PVH", because then Xen
>>> will be tied to always providing the same set of devices in PVH
>>> containers.
>>
>> Why? This would depend on the semantics tied to the flag. It could just
>> mean "don't assume availability of legacy stuff" (e.g. BIOS calls).
>>
>> Linux would have a problem with the ACPI approach as it would try BIOS
>> calls way before it is initializing its ACPI handling. So in Linux I'd
>> need another way to tell I'm running in PVH mode, e.g. a "no legacy"
>> bit in the Xen HVM cpuid leaf.
> 
> If you are booted from the PVH entry point, there's no BIOS or UEFI
> (ie: no firmware), if you are booted from the BIOS entry point there's
> a BIOS and the same applies to UEFI. How does Linux differentiate
> whether it's booted from BIOS or UEFI?

They use different entries.


Juergen




reply via email to

[Prev in Thread] Current Thread [Next in Thread]