WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Stephen C. Tweedie" <sct@xxxxxxxxxx>
Subject: [Xen-devel] Re: Illegal PV kernel pfm/pfn translations on PROT_NONE ioremaps
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 19 Mar 2008 16:42:09 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>
Delivery-date: Wed, 19 Mar 2008 09:43:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1205944282.7277.32.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AciJ4CxcasiJO/XTEdyyLQAX8io7RQ==
Thread-topic: Illegal PV kernel pfm/pfn translations on PROT_NONE ioremaps
User-agent: Microsoft-Entourage/11.4.0.080122
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