Re: [Xen-devel] PV audio drivers for Linux

[Oleksandr Andrushchenko <andr2000@xxxxxxxxx>]

On 01/18/2017 08:52 PM, Stefano Stabellini wrote:
> On Wed, 18 Jan 2017, Ughreja, Rakesh A wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:sstabellini@xxxxxxxxxx]
> > > Sent: Wednesday, January 18, 2017 5:41 AM
> > > To: Ughreja, Rakesh A <rakesh.a.ughreja@xxxxxxxxx>
> > > Cc: xen-devel@xxxxxxxxxxxxx; Oleksandr_Andrushchenko@xxxxxxxx;
> > > Oleksandr_Grytsov@xxxxxxxx; oleksandr.dmytryshyn@xxxxxxxxxxxxxxx;
> > > iurii.konovalenko@xxxxxxxxxxxxxxx; konrad.wilk@xxxxxxxxxx
> > > Subject: Re: [Xen-devel] PV audio drivers for Linux
> > >
> > > On Tue, 17 Jan 2017, Ughreja, Rakesh A wrote:
> > > > Hi,
> > > >
> > > > I am trying to develop PV audio drivers and facing one issue to
> > > > achieve zero copy of the buffers between Front End (DOM1) and
> > > > Back End (DOM0) drivers.
> > > You might want to take a look at the existing PV sound proposal:
> > >
> > > http://marc.info/?l=xen-devel&m=148094319010445
> > Sure, let me look into this.
> > Thank you very much for the quick reply and the reference.
> >
> > > > When the buffer is allocated using __get_free_pages() on the DOM0
> > > > OS, I am able to grant the access using gnttab_grant_foreign_access()
> > > > to DOM1 as well as I am able to map it in the DOM1 virtual space
> > > > using xenbus_map_ring_valloc().
> > > >
> > > > However the existing audio driver allocates buffer using
> > > > dma_alloc_coherent(). In that case I am able to grant the access using
> > > > gnttab_grant_foreign_access() to DOM1 but when I try to map in the
> > > > DOM1 virtual space using xenbus_map_ring_valloc(), it returns an error.
> > > >
> > > > [1] Code returns from here.
> > > >
> > > > 507                         xenbus_dev_fatal(dev, map[i].status,
> > > > 508                                          "mapping in shared page %d from domain 
> > > > %d",
> > > > 509                                          gnt_refs[i], dev->otherend_id);
> > > >
> > > > gnttab_batch_map(map, i) is unable to map the page, but I am unable to
> > > > understand why. May be its due to the difference in the way buffers
> > > > are allocated dma_alloc_coherent() vs __get_free_pages().
> > > >
> > > > Since I don't want to touch existing audio driver, I need to figure out
> > > > how to map buffer to DOM1 space with dma_alloc_coherent().
> > > >
> > > > Any pointers would be really helpful. Thank you in advance.
> > > Pages allocated by dma_alloc_coherent can be a bit special. Are you
> > > going through the swiotlb-xen
> > > (drivers/xen/swiotlb-xen.c:xen_swiotlb_alloc_coherent) in Dom0?
> > No, I am not using this.
> Keep in mind that when swiotlb-xen is used, it is transparent from the
> device driver point of view. You might be using it without knowing. I
> suggest you add a printk in there to be sure.
>
>
> > Actually I am trying to reuse the existing
> > HDA driver and just opening the ALSA streams at kernel level in
> > PV Backend driver.
> >
> > Buffers are allocated by the existing HDA driver.
> > http://lxr.free-electrons.com/source/sound/core/memalloc.c#L83
> >
> > > I would probably add a few printks to Xen in
> > > xen/common/grant_table.c:do_grant_table_op to understand what is the
> > > error exactly.
> > In the gnttab_retry_eagain_gop function, when it tries to
> > get the status it always receives status as GNTST_eagain. After the retries
> > the status is marked as GNTST_bad_page.
> >
> > I am unable to figure out what properties of dma_alloc_coherent allocated
> > buffers makes it un-mappable at Dom1.
> Nothing comes to mind, but maybe the x86 maintainers (CC'ed) know.
just a guess. please check [1]. I had problems mapping

dma_alloc_coherent pages in DomU because of

vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);

which cannot be done in unprivileged domain

Regards,
Oleksandr

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> https://lists.xen.org/xen-devel
[1] https://lists.xen.org/archives/html/xen-devel/2016-11/msg02882.html

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