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] Re: Illegal PV kernel pfm/pfn translations on PROT_NONE iore

To: "Stephen C. Tweedie" <sct@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: Illegal PV kernel pfm/pfn translations on PROT_NONE ioremaps
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 19 Mar 2008 16:00:35 +0000
Cc: Jan Beulich <jbeulich@xxxxxxxxxx>
Delivery-date: Wed, 19 Mar 2008 09:02:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1205941191.7277.9.camel@xxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AciJ2l3SnHtPI/XNEdyyLQAX8io7RQ==
Thread-topic: Illegal PV kernel pfm/pfn translations on PROT_NONE ioremaps
User-agent: Microsoft-Entourage/11.4.0.080122
Return ~mfn in this case? Still fails the usual is-it-a-valid-pfn tests, but
can be picked up and converted back to a valid mfn by pfn_to_mfn(). The key
is that most of the time invalid pfns are explicitly == end_pfn, or
max_page, or similar, so we are distinguishing from those and also can still
bug on that specific value in pfn_to_mfn().

As for picking this up in the save/restore code -- sounds a bit tricky to
me. We're better off not allowing migration of a I/O-privileged domain in
the first place. And indeed I believe the tools already have some such
safety checks.

 -- Keir

On 19/3/08 15:39, "Stephen C. Tweedie" <sct@xxxxxxxxxx> wrote:

> 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