[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Kernel panic with tboot E820_UNUSABLE region
>>> On 14.05.13 at 19:16, David Vrabel <david.vrabel@xxxxxxxxxx> wrote: > On 14/05/13 18:02, Konrad Rzeszutek Wilk wrote: >> David Vrabel <david.vrabel@xxxxxxxxxx> wrote: >> >>> On 14/05/13 15:46, Jan Beulich wrote: >>>>>>> On 14.05.13 at 16:33, Aurelien Chartier >>> <aurelien.chartier@xxxxxxxxxx> 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. But then they must not be 1:1 mapped. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |