On 18/09/17 10:57, Jakub Jermar wrote:
Now, let me go straight to my issue. I am observing lots of invocations
of rumpcomp_pci_virt_to_mach() on addresses that were allocated by
rumpuser_malloc(). As rumpuser_malloc() allocates ordinary unpinned host
virtual memory, it does not make sense to me to translate it into host
physical memory; and on L4Re this is not possible at all, so the
translation cannot be performed.
I found that this memory is allocated by the pool_page_alloc() as
eventually invoked from wm_add_rxbuf() and the
rumpcomp_pci_virt_to_mach() is attempted from bus_dmamap_load_mbuf()
also invoked from wm_add_rxbuf(). The detailed stack traces follow at
the end of this e-mail.
Now, my question is how to handle this situation. I noticed that both
Hurd and Linux print a warning and return 0 if they cannot find the
translation. But is it even sensible to invoke
rumpcomp_pci_virt_to_mach() on something which was not allocated by
rumpcomp_pci, ie. rumpcomp_pci_dmalloc()? Should an identity mapping be
assumed here, just as in the case of the rump version of vtophys(). I
could also modify rumpuser to always pin the allocated memory, but that
would be a huge overkill for other invocations of rumpuser_malloc().
What the code is trying to do is figure out the address of the network
buffer in the "dma space". Since those buffers are not larger than a
page nor require special alignment/boundary conditions, they aren't
specially allocated. You do have to return the corresponding dma-able
address, for I daresay obvious reasons.
Now, the only thing I remember about the PCI code is that I spent zero
thought on it. So, don't make the mistake of assuming that the PCI
code/interfaces make sense and were carefully analyzed to ensure that
they will work on every possible platform.
I guess you could add a side-effect to virt_to_mach() to ensure that the
addresses it is called on have a dma-able backing, possibly by tearing
down the existing mapping and plugging a new one in there. Of course,
I'm not sure if that's possible on L4Re, or if such a hack would violate
assumptions elsewhere, but at least seems like a minimal-jackhammer
approach. You could also check what the seL4 people did, assuming the
same problem exists there; though, I'm not sure if their code is
available and/or if they're on this list.
