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