Re: L4Re: Allocating pinned memory and obtaining its physical address
Philipp Eppelt <[email protected]> Tue, 23 May 2023 16:03:28 +0200
| Newsgroups | gmane.comp.micro-kernel.l4.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Paul, On 5/23/23 00:51, Paul Boddie wrote: > On Sunday, 23 April 2023 10:09:52 CEST Jakub Jermář wrote: >> >> The idea is that you have a dataspace and a DMA space. In order to >> obtain a DMA address that you can then use to program your I/O device, >> you need to map a portion of the dataspace into the DMA space. After use >> you unmap it from the DMA space. >> >> See for example the implementation of the Inout buffer in our nvme-driver: >> >> https://github.com/kernkonzept/nvme-driver/blob/master/server/src/ > inout_buffer.h#L46 > > I also looked at the main.cc file to see how I might obtain a DMA space and > assign it to a DMA domain. Obtaining a DMA space appears to involve invoking a > factory create operation using the L4RE_PROTO_DMA_SPACE protocol. > > Here, I found a difference between the L4Re C and C++ libraries, with the > latter referencing a "user_factory" but defining it as the memory allocator, > so I just used the mem_alloc member of the environment structure in C for the > factory. In C++ mem_alloc and user_factory are nearly the same. Mem_alloc extends the factory protocol with allocation for dataspaces. At the moment, this is effectively a convenience wrapper, as both are using the same capability index and thus talk to the same server. The reason for the user_factory name is to be able to write less confusing code, e.g. where one would use mem_alloc to create some non-memory objects. > > With a DMA space, it should supposedly be possible to specify ~0U (or -1, I > guess) as the domain identifier when assigning the space to a domain, but this > does not work and yields the following warning: > > IO | vbus vbus does not support a global DMA domain > > This along with an error indicating "No such object found". > > The main.cc file in the nvme-driver performs a search for a DMA domain > resource, but replicating this myself produces a few issues. First of all, a > search from the root device doesn't manage to find a resource offering a DMA > domain if I traverse devices and their resources. > > However, I see that the hw_root_bus.cc file in pkg/io/io/server/src adds root > resources for a DMA domain, amongst other things, and if I also investigate > the resources of the root device itself, then I do find such resources. > Strangely, these resources appear to have an identifier of zero after they > have been added to the bus, even though they get set up with expected > identifiers such as "DMAD". > > Meanwhile, in the main.cc file in pkg/io/io/server/src, a DMA domain resource > is explicitly created when no iommu capability is provided to the server. This > actually appears in the dump of the devices and resources at the system bus > level, as produced by Io, but not within the vbus. > > So, I think I need some suggestions as to how I can actually obtain a domain > identifier and maybe how a domain should be made available in the .io file. > Sorry if I failed to understand what to do, but none of this is particularly > obvious to me. The path you are on sounds correct. A reason for a missing DMA domain resource on the vbus is (usually) the lack of a DMA capable device on said vbus. https://github.com/kernkonzept/manifest/wiki/NVMeWithLinux#vbus-configuration-file shows a vbus configuration file that places all PCI/storage devices on the vbus. I presume your MIPS board lacks PCI, so you have to write the entries for System_bus and the Vbus yourself. The helpful sections in another tutorial are: https://github.com/kernkonzept/manifest/wiki/HwPassThrough#ios-config-file https://github.com/kernkonzept/manifest/wiki/HwPassThrough#vbus-configuration-file I found your mercurial instance for the l4re topic but didn't find any io & vbus configuration. Can you point me to your config files? And/Or send along the Io output with maximum verbosity (-vvvvvvv)? Cheers, Philipp _______________________________________________ l4-hackers mailing list [email protected] https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
OpenPGP_signature
(application/pgp-signature, 840 B) - not displayed