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

Re: [Xen-devel] Xen crash: map_domain_page() on an NMI path

On 27/12/2013 07:29, Kai Huang wrote:

On Fri, Dec 20, 2013 at 4:43 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>> On 19.12.13 at 17:19, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> However, for hardware pieces like this which are set up once at the
> start of day, and have the hardware pointed at a chosen region, would it
> be acceptable to allocate their frames low enough to be covered by the
> direct map area (protected by BUG()s?) and set up their base virtual
> addresses knowing that there will always be a valid mapping from any Xen
> pagetables?  This seems better than constantly playing around with the
> mappings.

That would still require further special casing in map_domain_page().

In the case here, and with 32-bit no longer a concern, a virtual
mapping should rather be obtained at boot time once and for all
using vmap().

A question about map_domain_page. If I understand correctly, currently map_domain_page will still do page table setup with virtual address in mapcache area. Why can't we just map all physical memory to XEN's  virtual address slot, and do mfn_to_virt to get the virtual address?


Xen hands most of the upper canonical half to 64bit PV guest kernels.

The first 5TiB of RAM is unconditionally available via mfn_to_virt, but Xen supports up to 16TiB of RAM.

Therefore, a server with more than 5TiB of RAM, or with RAM hoplug regions above the 5TiB boundary require domain mappings to be accessed.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.