search for: rpmesg

...size, dir); > > However we are using per device dma area for rpmsg, phys_to_virt > > could not return a correct virtual address for virtual address in > > vmalloc area. Then kernel panic. > > > > I must be missing something. Maybe it is because it has to do with RPMesg? > > I think it's an RPMesg bug, yes rpmsg bug is another issue, it should not use dma_alloc_coherent for reserved area, and use vmalloc_to_page. Anyway here using dma api will also trigger issue. > > > > > > > > > You might have noticed that I missed one p...

...size, dir); > > However we are using per device dma area for rpmsg, phys_to_virt > > could not return a correct virtual address for virtual address in > > vmalloc area. Then kernel panic. > > > > I must be missing something. Maybe it is because it has to do with RPMesg? > > I think it's an RPMesg bug, yes rpmsg bug is another issue, it should not use dma_alloc_coherent for reserved area, and use vmalloc_to_page. Anyway here using dma api will also trigger issue. > > > > > > > > > You might have noticed that I missed one p...

...t; However we are using per device dma area for rpmsg, phys_to_virt > > > could not return a correct virtual address for virtual address in > > > vmalloc area. Then kernel panic. > > > > > > I must be missing something. Maybe it is because it has to do with RPMesg? > > > > I think it's an RPMesg bug, yes > > rpmsg bug is another issue, it should not use dma_alloc_coherent for reserved area, > and use vmalloc_to_page. > > Anyway here using dma api will also trigger issue. Is the stack trace above for the RPMesg issue or for...

...Just to stress - with a patch like this virtio can *still* use DMA API > if PLATFORM_ACCESS is set. So if DMA API is broken on some platforms > as you seem to be saying, you guys should fix it before doing something > like this.. Yes, DMA API is broken with some interfaces (specifically: rpmesg and trusty), but for them PLATFORM_ACCESS is never set. That is why the errors weren't reported before. Xen special case aside, there is no problem under normal circumstances. If you are OK with this patch (after a little bit of clean-up), Peng, are you OK with sending an update or do you wan...

...Just to stress - with a patch like this virtio can *still* use DMA API > if PLATFORM_ACCESS is set. So if DMA API is broken on some platforms > as you seem to be saying, you guys should fix it before doing something > like this.. Yes, DMA API is broken with some interfaces (specifically: rpmesg and trusty), but for them PLATFORM_ACCESS is never set. That is why the errors weren't reported before. Xen special case aside, there is no problem under normal circumstances. If you are OK with this patch (after a little bit of clean-up), Peng, are you OK with sending an update or do you wan...

...d by Xen to ARM guests (no virtio-block/net, > > etc.) > > > > In fact, in both cases we are discussing virtio is *not* provided by > > Xen; it is a firmware interface to something entirely different: > > > > 1) virtio is used to talk to a remote AMP processor (RPMesg) > > 2) virtio is used to talk to a secure-world firmware/OS (Trusty) > > > > VIRTIO_F_ACCESS_PLATFORM is not set by Xen in these cases but by RPMesg > > and by Trusty respectively. I don't know if Trusty should or should not > > set VIRTIO_F_ACCESS_PLATFORM, but I...

...d by Xen to ARM guests (no virtio-block/net, > > etc.) > > > > In fact, in both cases we are discussing virtio is *not* provided by > > Xen; it is a firmware interface to something entirely different: > > > > 1) virtio is used to talk to a remote AMP processor (RPMesg) > > 2) virtio is used to talk to a secure-world firmware/OS (Trusty) > > > > VIRTIO_F_ACCESS_PLATFORM is not set by Xen in these cases but by RPMesg > > and by Trusty respectively. I don't know if Trusty should or should not > > set VIRTIO_F_ACCESS_PLATFORM, but I...

...t in Xen. Today there are still no virtio interfaces provided by Xen to ARM guests (no virtio-block/net, etc.) In fact, in both cases we are discussing virtio is *not* provided by Xen; it is a firmware interface to something entirely different: 1) virtio is used to talk to a remote AMP processor (RPMesg) 2) virtio is used to talk to a secure-world firmware/OS (Trusty) VIRTIO_F_ACCESS_PLATFORM is not set by Xen in these cases but by RPMesg and by Trusty respectively. I don't know if Trusty should or should not set VIRTIO_F_ACCESS_PLATFORM, but I think Linux should still work without issues....

...t in Xen. Today there are still no virtio interfaces provided by Xen to ARM guests (no virtio-block/net, etc.) In fact, in both cases we are discussing virtio is *not* provided by Xen; it is a firmware interface to something entirely different: 1) virtio is used to talk to a remote AMP processor (RPMesg) 2) virtio is used to talk to a secure-world firmware/OS (Trusty) VIRTIO_F_ACCESS_PLATFORM is not set by Xen in these cases but by RPMesg and by Trusty respectively. I don't know if Trusty should or should not set VIRTIO_F_ACCESS_PLATFORM, but I think Linux should still work without issues....

...ap_area(phys_to_virt(dma_to_phys(dev, dev_addr)), size, dir); However we are using per device dma area for rpmsg, phys_to_virt could not return a correct virtual address for virtual address in vmalloc area. Then kernel panic. I must be missing something. Maybe it is because it has to do with RPMesg? > > > > You might have noticed that I missed one possible case above: Xen/ARM > > > > DomU :-) > > > > > > > > Xen/ARM domUs don't need swiotlb_xen, it is not even initialized. So if > > > > (xen_domain) return true; would give th...

...ap_area(phys_to_virt(dma_to_phys(dev, dev_addr)), size, dir); However we are using per device dma area for rpmsg, phys_to_virt could not return a correct virtual address for virtual address in vmalloc area. Then kernel panic. I must be missing something. Maybe it is because it has to do with RPMesg? > > > > You might have noticed that I missed one possible case above: Xen/ARM > > > > DomU :-) > > > > > > > > Xen/ARM domUs don't need swiotlb_xen, it is not even initialized. So if > > > > (xen_domain) return true; would give th...

...> virtio interfaces provided by Xen to ARM guests (no virtio-block/net, > etc.) > > In fact, in both cases we are discussing virtio is *not* provided by > Xen; it is a firmware interface to something entirely different: > > 1) virtio is used to talk to a remote AMP processor (RPMesg) > 2) virtio is used to talk to a secure-world firmware/OS (Trusty) > > VIRTIO_F_ACCESS_PLATFORM is not set by Xen in these cases but by RPMesg > and by Trusty respectively. I don't know if Trusty should or should not > set VIRTIO_F_ACCESS_PLATFORM, but I think Linux should still...

...to_phys(dev, dev_addr)), size, dir); > However we are using per device dma area for rpmsg, phys_to_virt > could not return a correct virtual address for virtual address in > vmalloc area. Then kernel panic. > > I must be missing something. Maybe it is because it has to do with RPMesg? I think it's an RPMesg bug, yes. > > > > > > You might have noticed that I missed one possible case above: Xen/ARM > > > > > DomU :-) > > > > > > > > > > Xen/ARM domUs don't need swiotlb_xen, it is not even initialized. So...

...t; However we are using per device dma area for rpmsg, phys_to_virt > > > could not return a correct virtual address for virtual address in > > > vmalloc area. Then kernel panic. > > > > > > I must be missing something. Maybe it is because it has to do with RPMesg? > > > > I think it's an RPMesg bug, yes > > rpmsg bug is another issue, it should not use dma_alloc_coherent for reserved area, > and use vmalloc_to_page. > > Anyway here using dma api will also trigger issue. > > > > > > > > > > &g...

...per device dma area for rpmsg, phys_to_virt > > > > could not return a correct virtual address for virtual address in > > > > vmalloc area. Then kernel panic. > > > > > > > > I must be missing something. Maybe it is because it has to do with > RPMesg? > > > > > > I think it's an RPMesg bug, yes > > > > rpmsg bug is another issue, it should not use dma_alloc_coherent for > > reserved area, and use vmalloc_to_page. > > > > Anyway here using dma api will also trigger issue. > > > > &g...

...per device dma area for rpmsg, phys_to_virt > > > > could not return a correct virtual address for virtual address in > > > > vmalloc area. Then kernel panic. > > > > > > > > I must be missing something. Maybe it is because it has to do with > RPMesg? > > > > > > I think it's an RPMesg bug, yes > > > > rpmsg bug is another issue, it should not use dma_alloc_coherent for > > reserved area, and use vmalloc_to_page. > > > > Anyway here using dma api will also trigger issue. > > > > &g...

...patch like this virtio can *still* use DMA API > > if PLATFORM_ACCESS is set. So if DMA API is broken on some platforms > > as you seem to be saying, you guys should fix it before doing something > > like this.. > > Yes, DMA API is broken with some interfaces (specifically: rpmesg and > trusty), but for them PLATFORM_ACCESS is never set. That is why the > errors weren't reported before. Xen special case aside, there is no > problem under normal circumstances. So why not fix DMA API? Then this patch is not needed. > > If you are OK with this patch (afte...

On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote: > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > > > > Export xen_swiotlb for all platforms using xen swiotlb > > > > > > > > Use xen_swiotlb to determine when

On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote: > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > > > > Export xen_swiotlb for all platforms using xen swiotlb > > > > > > > > Use xen_swiotlb to determine when