[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Kieran Mansley <kmansley@xxxxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcgmGGXbpHUkHpILEdytjwAX8io7RQ==
  • Thread-topic: [Xen-devel] [PATCH] grant table and bogus mfns

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.