Re: Kernel panic with tboot E820_UNUSABLE region

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, May 14, 2013 at 06:16:27PM +0100, David Vrabel wrote:
> On 14/05/13 18:02, Konrad Rzeszutek Wilk wrote:
> > David Vrabel <david.vrabel@citrix.com> wrote:
> > 
> >> On 14/05/13 15:46, Jan Beulich wrote:
> >>>>>> On 14.05.13 at 16:33, Aurelien Chartier
> >> <aurelien.chartier@citrix.com> wrote:
> >>>
> >>> With
> >>>
> >>>> (XEN)  0000000000100000 - 0000000000800000 (usable)
> >>>> (XEN)  0000000000800000 - 0000000000975000 (unusable)
> >>>> (XEN)  0000000000975000 - 0000000020000000 (usable)
> >>>> ...
> >>>> The region 0000000000975000 - 0000000020000000 has been set to
> >> unusable
> >>>> by tboot.
> >>>
> >>> ... you certainly mean the range 800000-975000.
> >>>
> >>>> Calls to update_va_mapping show the following error messages (with
> >> mfn
> >>>> going from 800 to 974):
> >>>>
> >>>> (XEN) mm.c:911:d0 Error getting mfn 800 (pfn 5555555555555555) from
> >> L1
> >>>> entry 0000000000800463 for l1e_owner=0, pg_owner=0
> >>>
> >>> Yes, the kernel has no business mapping that region, and the
> >>> hypervisor rightly refuses the attempt.
> >>
> >> Ok, so this is Xen checking the new PTE supplied in the
> >> update_va_mapping hypercall and saying no.
> >>
> >> I think there are two things the kernel can do here.
> >>
> >> a) Change the type of UNUSABLE regions to RAM.
> >>
> >> b) Release pages overlapping UNUSABLE regions, destroy their mapping
> >> and
> >> clear/invalidate the region in the p2m.
> >>
> >> Option a) is probably the easiest.
> >>
> >> David
> > 
> > But option b) seems the proper one.
> 
> Well...  The pfns currently overlapping the machine's UNUSABLE region
> are usable RAM and nothing else is the kernel will want to access any
> machine address within this region (and evidently can't, even if it
> wanted to!).
> 
> If it helps, think of it as dom0 taking the pseudo-physical memory map
> and putting holes in it to corresponding to interesting bits of the
> machine memory map.  UNUSABLE regions aren't interesting so we don't
> make holes for them.

We do in the Linux's P2M. We mark them as 1:1, meaning that they the
MFNs we get from the P2M should be the PFN value. And the M2P.. well
that looks to be always 55555.

And that logic looks to be same irregardless if the regions are
E820_RESERVED, E820_UNUSABLE or just MMIO gaps. This is looking at
xen_set_identity_and_release which calls the
xen_set_identity_and_release_chunk (which calls set_phys_range_identity
to set the P2M for 1-1 mapping).

I think I am missing something?
Or when you say 'p2m' you are referring to the hypervisor's direct map?