Re: Kernel panic with tboot E820_UNUSABLE region

[David Vrabel <david.vrabel@citrix.com>]

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.

David