Problems with DMA on Genode+NOVA

[Norman Feske]

Hi Christian

welcome to the mailing list!

> I'm trying to run Genode+NOVA on a Panasonic Toughpad FZ-M1. I'm new to Genode 
> but thanks to documentation and good coding style I came along pretty good so 
> far. However, I ran into a problem with DMA.
> 
> I tried to run the AHCI driver, but whenever the driver issued the first SATA-
> command, the hardware failed because it was not able to read from the specified 
> DMA address. After I enabled IOMMU by adding 'pci_device_pd' to my modules, I 
> got the message "[init -> acpi -> pci_drv -> oci_device_pd] attachment of DMA 
> memory @ cb48c000+1000 failed". 
> 
> I investigated more into the memory allocation process. As far as I understand 
> it, the method 'alloc_dma_buffer' of the PCI session first allocates a dataspace 
> in physical memory. Then it tries to attach this dataspace as a region to the 
> driver's virtual address space. Thereby it enforces the virtual address to be 
> equal to the physical address. So the allocator  searches for a free block 
> that contains that virtual address. But in my case it doesn't find a free 
> block.

Your analysis is very good. The problem is that the allocation of the
DMA buffer returned a very high physical address (above 0xc000000). So
when the device PD tries to create a 1:1 mapping for this block, it
attempts to create a mapping to the corresponding virtual address. But
the NOVA kernel preserves all virtual addresses above 0xc0000000 for the
kernel. Because Genode's core is aware of this constraint, it excludes
the address range above 0xc0000000 from the virtual-memory allocators
(that is maintained per process). This problem is related to the
following issue:

  https://github.com/genodelabs/genode/issues/1045

There three possible ways to cope with the problem:

* As a work-around, we could remove all physical memory above 0xc0000000
  from core's physical-memory allocator. But that would be a pity
  because Genode could not use all the memory of your system.

* You could use NOVA on 64 bit instead of 32 bit. Here, the kernel's
  virtual address space won't interfere with the physical memory address
  space.

* We could add a constraint to Genode's RAM sessions to enable a RAM
  client to specify a physical memory range from where the allocations
  should come from. So the PCI/ACPI driver would then limit this range
  to 0x00000000 - 0xbfffffff. This approach would solve your problem as
  well as the issue cited above.

I think the quickest way forward would be to switch to 64 bit. Would
that be feasible for you?

> 
> Do you have any ideas on how to resolve this issue? What I don't understand is 
> why physical and virtual address of the dma buffer should be equal. Shouldn't 
> there by some mechanism that ensures that there is a free block that contains 
> the DMA address before the DMA buffer is allocated in physical memory?
> 
> Tell me if you need any specification on the device. I would like to print the 
> full Log here, but unfortunately I have no serial interface, I am only able to 
> use a vga console.

Does you platform support Intel AMT by any chance? It would be
worthwhile to use it.

Btw, are you located in Dresden? If yes, you are very welcome to drop by
at our office - e.g., if you like us to assist you with setting up AMT.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth