On 06/11/17 12:36, 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.
>
> I looked through the xen_pvh_domain() use cases in the Linux kernel
> again.
>
> Maybe we can really manage to not need differentiating PVH from HVM
> until ACPI table scan. We'd need another hook for Xen, but this should
> be easy as KVM already has a hook where we'd need one. So this can be
> made more general and we are fine.
>
> I even think we can drop some of the PVH tests, as the PVH-specific
> handling (e.g. for grant table initialization) should work for HVM, too.
So I did a little test now: with some small patches added I've managed
to boot a PVH Linux kernel without any special handling in the early
PVH paths of the kernel (only setting up initial page tables and faking
a memory map similar to the one grub would deliver). PVH detection is
done via ACPI table ("VGA Not Present" and "CMOS RTC Not Present" in a
HVM domain will result in PVH assumed).
If nobody objects to this handling I'll send patches soon.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
