[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v7 2/4] xen/arm: grant: Add another entry to map MFN 1:1 in dom0 p2m
On 05/19/2014 10:45 AM, Ian Campbell wrote: > On Sat, 2014-05-17 at 19:12 +0100, Julien Grall wrote: >> >> On 15/05/14 15:16, Julien Grall wrote: >>> Grant mapping can be used for DMA request. The dev_bus_addr returned by the >>> hypercall is the MFN (not the IPA). Currently Linux is using this address >>> (via >>> swiotlb) to program the DMA. >>> When the device is protected by IOMMU the request will fail. We have to >>> add 1:1 mapping in the domain p2m to allow DMA request working. >>> >>> This is valid because DOM0 has its memory mapped 1:1 and therefore we know >>> that RAM and devices cannot clash. >> >> I though a bit more about this patch. It doesn't handle the case where 2 >> grant use the same MFN, which is valid. >> >> In this case, we should remove the 1:1 mapping only when the last grant >> is removed. >> >> I'm not sure how to handle this case. > > Urk, yes indeed. > > This is all hypervisor side stuff I think, right? There is 2 issues (one in hypervisor side, the other in DOM0). The issue I'm talking here is in the hypervisor side. > I wonder if the grant table maptrack stuff is helpful here, i.e. could > it contain a reference count (if it doesn't already)? Some care and > attention would be needed to make it safe, but it might be doable. It seems that mapcount (common/grant_table.c), do the job for us. I will give a look on it. The other issue (from DOM0 side) comes from the swiotlb implementation for ARM (see arch/arm/xen/p2m.c). We are unable to handle multiple PFN linked to a same MFN. This case will be silently ignore and still work (???). This is happening with Freebsd on ARM when portsnap is executed for the first time. I'm not sure why. Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |