On 1/27/20 3:07 PM, Xia, Hongyan wrote: > On Mon, 2020-01-27 at 15:43 +0100, Jan Beulich wrote: >> On 27.01.2020 15:33, Xia, Hongyan wrote: >>> ... >>> >>> Reflecting back to your comment in v3 about whether the new Xen >>> page >>> table mapping APIs (map/unmap_xen_pagetable) are really necessary, >>> I >>> agree in the end they will just do the same thing as >>> map/unmap_domain_page, although one thing is that the latter >>> suggests >>> it is trying to map a `domain' page, whose definition probably does >>> not >>> include Xen page tables, so the name could be a bit confusing >>> (well, we >>> could argue that Xen page tables are just idle `domain' pages so >>> the >>> name still holds). If we are happy with using map_domain_page on >>> Xen >>> PTE tables then I am okay with dropping the new mapping APIs and >>> only >>> include the new alloc APIs. >> >> Anyone on the To: list - opinions? > > There is one argument. We already use map_domain_page on non-domain > pages and outside the domheap. For example, the trap handler walks page > tables and print traces via map_domain_page regardless of where the > underlying page is from. The mapped page could just be from Xen.
Yes, I've long sort of mentally filtered out the 'domain' part of "map_domain_page()"; it's really an artifact of a bygone era, when there were separate xen and domain heaps. (In fact, it's really "map domheap page", and at the moment we only have a domheap.) It might be worth thinking about doing a global s/map_domain_page/map_page/; but until then, I think it's fine to use "map_domain_page" for "map pages in the domheap", given that there *is* only the domheap. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
