Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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