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
|
Home