[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document
On Tue, 14 Feb 2017, Julien Grall wrote: > Hi Stefano, > > On 02/13/2017 07:59 PM, Stefano Stabellini wrote: > > On Mon, 13 Feb 2017, Julien Grall wrote: > >> Hi Stefano, > >> > >> On 10/02/17 01:01, Stefano Stabellini wrote: > >>> On Fri, 3 Feb 2017, Edgar E. Iglesias wrote: > >>>> A possible hack could be to allocate a chunk of DDR dedicated for PCI > >>>> DMA. > >>>> PCI DMA devs could be locked in to only be able to access this mem + MSI > >>>> doorbell. > >>>> Guests can still screw each other up but at least it becomes harder to > >>>> read/write directly from each others OS memory. > >>>> It may not be worth the effort though.... > >>> > >>> Actually, we do have the swiotlb in Dom0, which can be used to bounce > >>> DMA requests over a buffer that has been previously setup to be DMA safe > >>> using an hypercall. That is how the swiotlb is used on x86. On ARM it is > >>> used to issue cache flushes via hypercall, but it could be adapted to do > >>> both. It would degrade performance, due to the additional memcpy, but it > >>> would work, I believe. > >> > >> A while ago, Globallogic suggested to use direct memory mapping for the > >> guest > >> to allow guest using DMA on platform not supporting SMMU. > >> > >> I believe we can use the same trick on platform where SMMUs can not > >> distinguish PCI devices. > > > > Yes, that would work, but only on platforms with a very limited number > > of guests. However, it might still be a very common use-case on a > > platform such as the Zynq MPSoC. > > Can you explain why you think this could only work with limited number > of guests? Because the memory regions would need to be mapped 1:1, right? And often devices have less than 4G DMA addresses limitations? I can see how it could work well with 1-4 guests, but I don't think it could work in a typical server environment with many more guests. Or am I missing something? _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |