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

Re: [Xen-devel] arm: Boot allocator fails with multi node memory



On Mon, 16 Jan 2017, Julien Grall wrote:
> Hi Jan,
> 
> On 09/01/17 08:40, Jan Beulich wrote:
> > > > > On 07.01.17 at 07:05, <vijay.kilari@xxxxxxxxx> wrote:
> > > Question: Why this address is not mapped?. If mapped where this va is
> > > mapped?.
> > 
> > Well, I think this is the wrong question to ask. Why would it be mapped
> > if there's no memory there?
> > 
> > > (XEN) Walking Hypervisor VA 0x847fffffffff on CPU0 via TTBR
> > > 0x00000000ffcf8000
> > > (XEN) 0TH[0x108] = 0x0000000000000000
> > > 
> > > 
> > > static unsigned long init_node_heap(int node, unsigned long mfn,
> > >                                     unsigned long nr, bool_t *use_tail,
> > > int d)
> > > {
> > > #ifdef DIRECTMAP_VIRT_END
> > >     unsigned long eva = min(DIRECTMAP_VIRT_END, HYPERVISOR_VIRT_END);
> > > #endif
> > > 
> > > 
> > > ....
> > > 
> > >     else if ( nr >= needed &&
> > >               (mfn + needed) <= (virt_to_mfn(eva - 1) + 1) &&  // <===
> > > FAILS here
> > 
> > The assumption here is that a virtual address inside the direct map
> > can always be translated, and from your report I'm gaining the
> > understanding that this is simply not true on ARM (but the code
> > here pre-dates ARM iirc). If that assumption doesn't hold (and
> > cannot be made so), apart from adjusting the code here there may
> > need to be a full audit of common code to see whether there are\
> > any other such uses.
> 
> On ARM, the function virt_to_mfn uses the hardware to do the address
> translation. So if the virtual address is not mapped, it will fail.
> 
> This is different from the assumption made by the code and x86
> behavior. I'd still like to keep the current behavior on ARM as it is very
> handy to directly get debug information when the virtual address is not
> mapped. Stefano, do you have any opinions?

I think it is great to use the hardware to implement virt_to_mfn in the
general case, for both performance and simplicity. However, it is
important not to diverge too much from x86 to avoid this class of
problems in the future. In other words, the semantics of virt_to_mfn
must be the same on x86 and ARM. We can either:

1) change x86 to match ARM
This could be as simple as adding a check, only for debug builds, in the
x86 implementation of virt_to_mfn to make sure that the virtual address
passed is mapped or mappable, throw an error if it is not.

2) change ARM to match x86
Add a special case in the arm64 implementation of virt_to_mfn to check
if the address is in the directmap region and translate it directly,
without ATS1HR and friends, in that case.

Either way is fine by me.

_______________________________________________
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®.