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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 19/3/08 16:31, "Stephen C. Tweedie" <sct@xxxxxxxxxx> wrote:

> ~mfn on its own probably won't work, though.  On non-PAE, we store mfns
> in a pte that only has 20 bits for the information, so we have to deal
> with that restricted range.

Sure. Personally I could live with a solution that didn't work for non-PAE.
I guess that might not be the popular choice however. ;-)

> It might be easier to do this at the pte_machine_to_phys level instead,
> where we can potentially take advantage of other bits of the pte to
> encode the special casing.

Oh yes, the PAGE_IO type of trick I mentioned in my other email just now.

To expand on that -- we'd like a PAGE_IO flag for foreign and I/O mappings
anyway. It would simplify pte_pfn and similar routines which currently do a
nasty little MFN->PFN->MFN conversion check to detect such 'foreign'
mappings.

> Thinking about it, if a guest could be clearly marked as having IO
> permission, we could simply disable both save/migrate AND !PAGE_PRESENT
> pfn-to-mfn translation in one go, and solve both problems at once.
> 
> Would either SIF_INITDOMAIN or SIF_PRIVILEGED work for this?
> SIF_INITDOMAIN would be the safe fix for this particular dom0 case, I
> think.  We could do it for SIF_PRIVILEGED too, but ONLY if we were sure
> that such domains would never be migrated or saved (we'll corrupt
> PROT_NONE mappings if we migrate such domains.)

SIF_PRIVILEGED is no longer used. It's still set for dom0, but not for
hardware-capable domUs. It's tricky anyway, since a domU can be given
hardware capabilities after it has booted through mechanisms like
pciback-pcifront PCI hotplug.

 -- Keir



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