[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 13:50:11 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
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.
Juergen
- Re: [Xen-devel] Xen PVH support in grub2, Juergen Gross, 2017/11/03
- Re: [Xen-devel] Xen PVH support in grub2, Roger Pau Monné, 2017/11/03
- Re: [Xen-devel] Xen PVH support in grub2,
Juergen Gross <=
- Re: [Xen-devel] Xen PVH support in grub2, Roger Pau Monné, 2017/11/03
- Re: [Xen-devel] Xen PVH support in grub2, Juergen Gross, 2017/11/03
- Re: [Xen-devel] Xen PVH support in grub2, Boris Ostrovsky, 2017/11/03
- Re: [Xen-devel] Xen PVH support in grub2, Juergen Gross, 2017/11/03
- Re: [Xen-devel] Xen PVH support in grub2, Boris Ostrovsky, 2017/11/03
- Re: [Xen-devel] Xen PVH support in grub2, Juergen Gross, 2017/11/03
- Re: [Xen-devel] Xen PVH support in grub2, Juergen Gross, 2017/11/03
- Re: [Xen-devel] Xen PVH support in grub2, Boris Ostrovsky, 2017/11/03
- Re: [Xen-devel] Xen PVH support in grub2, Juergen Gross, 2017/11/03
- Re: [Xen-devel] Xen PVH support in grub2, Boris Ostrovsky, 2017/11/03