Re: [Xen-devel] PV drivers and zero copying

[Oleksandr Andrushchenko <andr2000@xxxxxxxxx>]

On 07/31/2017 12:47 PM, Julien Grall wrote:
> On 31/07/17 10:46, Oleksandr Andrushchenko wrote:
> > Hi, Julien!
> >
> >
> > On 07/31/2017 12:24 PM, Julien Grall wrote:
> > > (+ Joao)
> > >
> > > On 31/07/17 09:34, Oleksandr Andrushchenko wrote:
> > > > Hi, all!
> > > Hi Oleksandr,
> > >
> > > > The aim of this mail is to highlight and discuss possible 
> > > > approaches to
> > > > implementing zero copying for PV drivers. Rationale behind this is 
> > > > that
> > > > there
> > > > are use-cases when drivers operate with big shared buffers, e.g.
> > > > display, when
> > > > memory copying from front’s buffer into back’s one may 
> > > > significantly hit
> > > > performance of the system (for example, for para-virtual display 
> > > > running
> > > > at full
> > > > HD resolution at 60Hz it is approximately 475MB/sec).
> > > >
> > > > Assumptions (which actually fit ARM platforms, but can be extended to
> > > > other
> > > > platforms as well): Dom0 is a 1:1 mapped privileged domain, runs 
> > > > backend
> > > > driver/software DomU is an unprivileged domain without 1:1 memory
> > > > mapping, runs
> > > > frontend driver
> > > I would rather avoid to stick with this assumption on ARM. This was
> > > only meant to be a workaround for platform without IOMMU (see [1]) and
> > > we will get into trouble when using IOMMU.
> > You are correct, thank you
> > > For instance, there are no requirement to have the IOMMU supporting as
> > > many as address bits than the processor. So 1:1 mapping here will not
> > > be an option.
> > >
> > > > Buffer origin: while implementing zero copying the buffer 
> > > > allocation can
> > > > happen
> > > > either on DomU’s end or Dom0’s one depending on the use-case and HW
> > > > capabilities/availability: When DomU allocates: It cannot guarantee
> > > > physical
> > > > memory continuity of the buffers allocated Dom0’s HW *can* handle
> > > > non-contiguous
> > > > memory buffers allocated by DomU for memory operations (DMA, for
> > > > example), e.g.
> > > > either with IOMMU help or by any other means (HW block’s own MMU).  
> > > > When
> > > > Dom0
> > > > allocates as it is mapped 1:1 it can allocate physically contiguous
> > > > memory
> > > > Dom0’s HW *cannot* handle non-contiguous memory buffers allocated by
> > > > DomU for
> > > > memory operations by any means.
> > > I am not sure to follow this. How zero copy is related to 1:1 mapping?
> > > Is it because you have hardware that does not support scatter/gather
> > > IO or IOMMU?
> > yes, you got it right
> Do you have any example of hardware? What are the performance you 
> require with them?
Currently our target is Renesas R-Car Gen3
At the moment I don't have clean requirements, but
ideally, PV driver introduces 0% performance drop
Some time soon I will have numbers on running display/GPU
with and without zero-copy - will keep updated
> Cheers,

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel