Re: [RFC] xen/pvh: detect PVH after kexec

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 03/21/2017 10:16 AM, Roger Pau Monne wrote:
> On Tue, Mar 21, 2017 at 10:05:27AM -0400, Boris Ostrovsky wrote:
>> On 03/21/2017 08:13 AM, Roger Pau Monne wrote:
>>> On Tue, Mar 21, 2017 at 12:53:07PM +0100, Vitaly Kuznetsov wrote:
>>>> Roger Pau Monne <roger.pau@citrix.com> writes:
>>>>> On Tue, Mar 21, 2017 at 10:21:52AM +0100, Vitaly Kuznetsov wrote:
>>>> I didn't investigate why it happens, setting xen_pvh=1 helped. Not sure
>>>> if it's related, but I see the following code in __gnttab_init():
>>>>
>>>> 	/* Delay grant-table initialization in the PV on HVM case */
>>>> 	if (xen_hvm_domain() && !xen_pvh_domain())
>>>> 		return 0;
>>>>
>>>> and gnttab_init() is later called in platform_pci_probe().
>>> But I guess this never happens in the PVH case because there's no Xen platform
>>> PCI device?
>>>
>>> Making the initialization of the grant tables conditional to the presence of
>>> the Xen platform PCI device seems wrong. The only thing needed for grant tables
>>> is a physical memory region. This can either be picked from unused physical
>>> memory (over 4GB to avoid collisions), or by freeing some RAM region.
>> That's because Linux HVM guests use PCI MMIO region for grant tables
>> (see platform_pci_probe()).
> There's no limitation in Xen that forces HVM guests to use the PCI MMIO hole of
> the Xen PCI device for the grant table. You can safely use a RAM region, or an
> unused physical range, probably above 4GB for safety. I'm not sure about what
> other things prevent booting a PVH guest using the same path as HVM, I guess
> the ACPI SCI interrupt is also one of them.


I think (hope?) using ACPI_IRQ_MODEL_PLATFORM for PVH guests takes care
of this.


>
> I wonder if it would make sense to announce using CPUID the things that differ
> from HVM (like the SCI over event channels), instead of simply advertising PVH.
> Boris, do you have a list of differences that prevent PVH from using the HVM
> code paths?

There isn't much, really. And most of them are discoverable already. For
example, we choose acpi_irq_model based on availability of IOAPICs,
which we find out by parsing MADT.

Similarly, for the problem at hand (lack of PCI platform device) we
should be able to just search PCI space and not find it, shouldn't we?
We may need to change order of how things are done.


-boris

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