Re: [Xen-devel] [PATCH v2 0/4] x86/shim: minor fixes to the pv-shim mode

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Dec 28, 2018 at 02:58:49PM +0000, Andrew Cooper wrote:
> On 28/12/2018 12:04, Roger Pau Monne wrote:
> > Hello,
> >
> > This series includes some miscellaneous fixes for the pv-shim mode,
> > specially regarding the handling of the memory map.
> 
> Unfortunately, something overall is now wonky.  With this series
> applied, I'm getting:
> 
> (d9) (XEN) Initial PVH-e820 RAM map:
> (d9) (XEN)  0000000000000000 - 00000000fc000000 (usable)
> (d9) (XEN)  00000000fc000000 - 00000000fc009040 (ACPI data)
> (d9) (XEN)  00000000feff8000 - 00000000ff000000 (reserved)
> (d9) (XEN)  0000000100000000 - 0000000104000400 (usable)
> (d9) (XEN) Checking MTRR ranges...
> (d9) (XEN)  MTRR cap: 508 type: 806
> (d9) (XEN) PVH-e820 RAM map:
> (d9) (XEN)  0000000000000000 - 00000000000a0000 (usable)
> (d9) (XEN)  00000000fc000000 - 00000000fc009040 (ACPI data)
> (d9) (XEN)  00000000feff8000 - 00000000ff000000 (reserved)
> (d9) (XEN)  0000000100000000 - 0000000104000400 (usable)
> 
> which a) is trying to account for the legacy range despite starting as a
> PVH guest.  (I think that perhaps cpu_has_hypervisor doesn't work that
> early, and I'll try making a fix for it.)

I've likely tested an stall version of the shim binary, sorry.

> b) The entire remainder of the RAM block which covered the legacy hole
> got deleted, so Xen failed to relocate itself and panic()'d

Hm, so the Linux function doesn't seem to work as expected.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel