| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: Illegal PV kernel pfm/pfn translations on PROT_NONE iore
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
|
|
|
| |
|
Home