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

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



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

Roger.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.