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

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

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Stephen C. Tweedie" <sct@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [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:34:57 +0000
Cc: Jan Beulich <jbeulich@xxxxxxxxxx>
Delivery-date: Wed, 19 Mar 2008 09:36:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C406E923.1E23D%keir.fraser@xxxxxxxxxxxxx>
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/XNEdyyLQAX8io7RQABM0Pp
Thread-topic: [Xen-devel] Re: Illegal PV kernel pfm/pfn translations on PROT_NONE ioremaps
User-agent: Microsoft-Entourage/11.4.0.080122
Another possibility, if we can modify all places that convert to/from
PROT_NONE (or otherwise specifically hook those places) would be to use a
software-available pte flag as PAGE_IO and avoid pte-mfn conversions on such
ptes.

I reckon the ~mfn trick, or similar mapping of untranslated mfns into the
pfn 'namespace', is the easier and more incremental solution.

 -- Keir

On 19/3/08 16:00, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

> 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



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