[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 03/10] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping
>>> On 04.05.16 at 11:13, <quan.xu@xxxxxxxxx> wrote: > On May 04, 2016 4:41 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >> >>> On 04.05.16 at 03:45, <kevin.tian@xxxxxxxxx> wrote: >> >> From: Xu, Quan >> >> Sent: Friday, April 29, 2016 5:25 PM >> >> --- a/xen/arch/x86/mm.c >> >> +++ b/xen/arch/x86/mm.c >> >> @@ -2467,7 +2467,7 @@ static int __get_page_type(struct page_info >> >> *page, unsigned long type, >> >> int preemptible) { >> >> unsigned long nx, x, y = page->u.inuse.type_info; >> >> - int rc = 0; >> >> + int rc = 0, ret = 0; >> >> >> >> ASSERT(!(type & ~(PGT_type_mask | PGT_pae_xen_l2))); >> >> >> >> @@ -2578,11 +2578,11 @@ static int __get_page_type(struct page_info >> >> *page, unsigned long type, >> >> if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) ) >> >> { >> >> if ( (x & PGT_type_mask) == PGT_writable_page ) >> >> - iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page))); >> >> + ret = iommu_unmap_page(d, mfn_to_gmfn(d, >> >> + page_to_mfn(page))); >> >> else if ( type == PGT_writable_page ) >> >> - iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)), >> >> - page_to_mfn(page), >> >> - IOMMUF_readable|IOMMUF_writable); >> >> + ret = iommu_map_page(d, mfn_to_gmfn(d, >> >> page_to_mfn(page)), >> >> + page_to_mfn(page), >> >> + >> >> + IOMMUF_readable|IOMMUF_writable); >> >> } >> >> } >> >> >> >> @@ -2599,6 +2599,9 @@ static int __get_page_type(struct page_info >> >> *page, unsigned long type, >> >> if ( (x & PGT_partial) && !(nx & PGT_partial) ) >> >> put_page(page); >> >> >> >> + if ( !rc ) >> >> + rc = ret; >> >> + >> >> return rc; >> >> } >> > >> > I know there were quite some discussions before around above change >> > (sorry I didn't remember all of them). Just based on mental picture we >> > should return error where it firstly occurs. However above change >> > looks favoring errors in later "rc = alloc_page_type" over earlier >> > iommu_map/unmap_page error. Is it what we want? >> >> Yes, as that's the primary operation here. >> >> > If there is a reason that we cannot return immediately upon >> > iommu_map/unmap, >> >> Since for Dom0 we don't call domain_crash(), we must not bypass >> alloc_page_type() here. And even for DomU it would seem at least fragile if >> we >> did - we better don't alter the refcounting behavior. >> > > A little bit confused. > Check it, for this __get_page_type(), can I leave my modification as is? Yes. I merely tried to explain the reason to Kevin. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |