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: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: Illegal PV kernel pfm/pfn translations on PROT_NONE ioremaps
From: "Stephen C. Tweedie" <sct@xxxxxxxxxx>
Date: Wed, 19 Mar 2008 16:31:22 +0000
Cc: Stephen Tweedie <sct@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>
Delivery-date: Wed, 19 Mar 2008 09:31:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C406E923.1E23D%keir.fraser@xxxxxxxxxxxxx>
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>
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
References: <C406E923.1E23D%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi,

On Wed, 2008-03-19 at 16:00 +0000, Keir Fraser wrote:
> Return ~mfn in this case? Still fails the usual is-it-a-valid-pfn tests,

Right... 

>  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().

Yep, it will still let pfn_to_mfn pick up that magic number --- it won't
catch corrupted ptes, though, which is a shame.

~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.

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.

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

Right, clearly.  Ideally, though, we'd make this mechanism robust, and
either have the HV fail the migrate if it finds such ptes, or
alternatively have the kernel BUG on the ptes if the guest is marked
migratable.

The latter sounds cleaner, but would require a mechanism to mark guests
as unmigratable/saveable while they have IO space mapped; I'm not sure
we have a clean way for marking such things right now.

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.)

Cheers,
 Stephen



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