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

Re: [Xen-devel] [PATCH] grant table and bogus mfns

To: Kieran Mansley <kmansley@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] grant table and bogus mfns
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 13 Nov 2007 17:12:41 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 13 Nov 2007 09:13:30 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1194973584.4124.42.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: AcgmGGXbpHUkHpILEdytjwAX8io7RQ==
Thread-topic: [Xen-devel] [PATCH] grant table and bogus mfns
User-agent: Microsoft-Entourage/11.3.6.070618
You make a good point. Let's instead allow the granter to explicitly specify
the cache attributes in the grant entry. We have space in the flags field.
Let's use bits 5,6,7 of that field. They can have the same format as the
three contiguous bits we have added in page->count_info. Conveniently, all
zeroes means map-WB-cacheable, which is the correct default.

 -- Keir

On 13/11/07 17:06, "Kieran Mansley" <kmansley@xxxxxxxxxxxxxx> wrote:

> On Tue, 2007-11-13 at 16:45 +0000, Keir Fraser wrote:
>> As for GNTMAP_nocache, I think actually we should not trust the mapper to
>> get the cache attributes correct (because sometimes if the attributes are
>> wrong the system can be destabilised).
> 
> Is this just (or mainly?) a concern for RAM pages?  If not, you'll have
> the same problem when using the domctl iomem_permission and
> ioremap_nocache() in the guest.
> 
>>  Actually we now in xen-unstable have
>> cache-attribute tracking for RAM pages. The cache attributes for the granted
>> mapping should pick up PAT/PWT/PCD from the page's count_info field. If dom0
>> has the page mapped with the right attributes this will then do the right
>> thing immediately. If dom0 doesn't have the page mapped then we'll need to
>> do a bit more work...
> 
> dom0 does have the page mapped, but I think there is no page_info struct
> (and so no count_info) for some I/O memory pages.  Perhaps a short-term
> fix would be to remove the GNTMAP_nocache option that I've added and
> instead just make all I/O memory pages that get mapped through this
> mechanism forced to _PAGE_PCD.  That way the mapper doesn't get to
> choose (and we loose the ability to do an ioremap() equivalent as
> opposed to an ioremap_nocache() equivalent, but that's not a big problem
> right now).  
> 
> If that sounds agreeable I can spin another patch.
> 
> Kieran 
> 



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