From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Re: Illegal PV kernel pfm/pfn translations on PROT_NONE ioremaps Date: Wed, 19 Mar 2008 16:34:57 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , "Stephen C. Tweedie" , "xen-devel@lists.xensource.com" Cc: Jan Beulich List-Id: xen-devel@lists.xenproject.org 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" 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" 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@lists.xensource.com > http://lists.xensource.com/xen-devel