From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Xen crash: map_domain_page() on an NMI path Date: Fri, 27 Dec 2013 11:38:35 +0000 Message-ID: <52BD66BB.9040105@citrix.com> References: <52B1F978.4090803@citrix.com> <52B308E702000078000A99D4@nat28.tlf.novell.com> <52B31C7A.5040802@citrix.com> <52B41131020000780010F654@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4530076984999276238==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Kai Huang , Jan Beulich Cc: keir@xen.org, tim@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============4530076984999276238== Content-Type: multipart/alternative; boundary="------------000905020706080403000301" --------------000905020706080403000301 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 27/12/2013 07:29, Kai Huang wrote: > > > > On Fri, Dec 20, 2013 at 4:43 PM, Jan Beulich > wrote: > > >>> On 19.12.13 at 17:19, Andrew Cooper > 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? > > -Kai 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. ~Andrew --------------000905020706080403000301 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 27/12/2013 07:29, Kai Huang wrote:



On Fri, Dec 20, 2013 at 4:43 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>> On 19.12.13 at 17:19, Andrew Cooper <andrew.cooper3@citrix.com> 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?

-Kai

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.

~Andrew
--------------000905020706080403000301-- --===============4530076984999276238== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4530076984999276238==--