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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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