WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Illegal PV kernel pfm/pfn translations on PROT_NONE ioremaps

To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Illegal PV kernel pfm/pfn translations on PROT_NONE ioremaps
From: "Stephen C. Tweedie" <sct@xxxxxxxxxx>
Date: Wed, 19 Mar 2008 15:39:51 +0000
Cc: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>
Delivery-date: Wed, 19 Mar 2008 08:40:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi,

On paravirt x86 (both 32- and 64-bit), since cset 13998:

        http://xenbits.xensource.com/xen-unstable.hg?rev/13998
        
we translate all ptes from being mfn-based to pfn-based when the
hardware _PAGE_PRESENT bit is cleared.  We do this for PROT_NONE pages,
which appear to the HV to be non-present, but which are special-cased in
the kernel to appear present (a different bit in the pte remains set for
these pages and is caught by the pte_present() tests.)

Unfortunately, it looks like recent X servers are attempting to do
mprotect(PROT_NONE) and back on regions of ioremap()ed memory.  When we
do so, the translation of mfn to pfn results on x86_64 in end_pfn:

maddr.h:
static inline unsigned long mfn_to_pfn(unsigned long mfn)
{
...
        if (unlikely((mfn >> machine_to_phys_order) != 0))
                return end_pfn;

and when we do mprotect(PROT_READ) later on on the same ptes, this
end_pfn value is illegal:

maddr.h:
static inline unsigned long pfn_to_mfn(unsigned long pfn)
{
        BUG_ON(end_pfn && pfn >= end_pfn);

so we BUG().

It needs both an updated X and an updated kernel to show the bug, but
given that, this results in an instant, completely repeatable kernel
panic on starting X on both 32- and 64-bits on some hardware.


Any suggestions?  The obvious fix is to special-case these mfn_to_pfn
translations so that they can be recognised as "untranslated" by a later
pfn_to_mfn, but ideally we'd want such special pfns to be easily
recognised so that we don't completely lose the value of the BUG_ON()
above.

We'd also ideally like the HV to be able to spot such pte contents, as
they won't (indeed, cannot) be translated on migrate.  That's not a
problem for dom0, of course, but might be for domUs with pci
passthrough .

Cheers,
 Stephen



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel