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

[Kieran Mansley <kmansley@xxxxxxxxxxxxxx>]

On Tue, 2007-11-13 at 17:12 +0000, Keir Fraser wrote:
> 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.

Attached is another spin of the patches to do this, based on a tree with
16067 reverted as requested.

>From the guest API point of view, previously gnttab_grant_foreign_access
() (and _ref()) took a "readonly" flag as an argument.  This is now a
more general flags field to allow the granter to specify the cache
attributes.  I also took the opportunity to remove the "readonly" flag
from gnttab_remove_foreign_access() as it was unused and I couldn't see
how to make useful in light of this change.

Within the hypervisor, the granter's specified cache attributes are
ignored at the point of mapping unless it is an I/O memory grant; for
RAM grants the cache attributes should I think be picked up
automatically using the cache-attribute tracking you mentioned, and this
seemed safer than allowing the granter to override.

In the case of an I/O memory map the granter-specified flags are passed
into create_grant_host_mapping() to add to the page table entry's flags.

I/0 memory maps using the grant table are only allowed in the case where
dom0 is doing the granting, the granter has iomem_access_permitted(),
GNTMAP_host_map is specified and GNTMAP_device_map is not.  Reference
counting using put_page/get_page is only done for those I/0 memory pages
that have mfn_valid()

I'm pretty happy with this now.  

Signed-off-by Kieran Mansley <kmansley@xxxxxxxxxxxxxx>

Thanks

Kieran

grant_cache_flags
Description: Text Data

iomem_page_test_fix
Description: Text Data

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