About pmap_mapdev() & pmap_unmapdev()

Kohji Okuno okuno.kohji at jp.panasonic.com
Sun Oct 5 11:23:55 UTC 2014

Hi Konstantin,

Thank you very much for your detailed explanatin.
I understood the policy of vmem.

Many thanks,
 Kohji Okuno

> On Sun, Oct 05, 2014 at 01:15:12PM +0900, Kohji Okuno wrote:
>> Hi,
>> > On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote:
>> >> Hi Konstantin,
>> >> 
>> >> Thank you for your prompt response.
>> >> I will test and report from next monday.
>> >> 
>> >> >> In addtion, I have one question.
>> >> >> In current and 10-stable, is vm_map_delete() called by kva_free()?
>> >> > No, kva_free() only releases the vmem backing, leaving the page
>> >> > tables intact.  This is why I only did the stable/9 patch.
>> >> 
>> >> Where are PTEs allocated by pmap_mapdev() freed in current and 10-stable?
>> >> Could you please explain me?
>> > They are not freed. The removal of the vmem which covers the address
>> > space managed by corresponding ptes, allows the reuse of both KVA region
>> > and corresponding PTEs in the tables. The only concern with the resident
>> > page tables is to avoid two kva_alloc() to step over each other, and
>> > this is ensured by vmem.
>> I agree that normal pages are reusable. But, since the pages mapped by
>> pmap_mapdev() are concerned with the physicall address of device (For
>> example: video memory), these PTEs aren't reusable, I think.
>> So, should we free these PTEs by pmap_unmapdev()?
> There is no hold on any physical pages which were referenced by the ptes.
> The only thing which is left out are the records in the page tables
> which map the KVA to said device memory.  It is harmless.
> When the KVA is reused, the ptes in page tables are overwritten.
> It might be argued that clearing PTEs, or at least removing the PG_V
> bit catches erronous unintended accesses to the freed range, but by the
> cost of the overhead of re-polluting the caches. And since clearing is
> not effective without doing TLB flush, which requires broadcast IPI,
> it is more trouble than advantage.
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"

More information about the freebsd-current mailing list