nullplan wrote:
rdos wrote:
The EHCI issue is not really a 32-bit vs 64-bit OS issue, rather an issue about physical addresses. A 32-bit OS using PAE can allocate 64-bit physical addresses.
The issue is that different devices can accept different physical addresses. And which addresses those are is a runtime property in at least some devices. And indeed that DMA addresses are different from physical addresses, at least in principle.
I think that is only in principle. There are some issues if you want to support multi-CPU setups with private address spaces, but apart from that, I think you can assume they are unity-mapped.
nullplan wrote:
rdos wrote:
Anyway, I solved it by considering the device to be a 32-bit device, and so it will always get addresses below 4GB. It's not worth the trouble of adding more complex physical memory allocators just so EHCI can get higher 4G blocks. I only have two physical address allocators: 32-bit and 64-bit. EHCI will use the 32-bit version, just like UHCI and OHCI. XHCI uses the 64-bit allocator.
So what do you do about ISA DMA?
I don't support it. I use PIO on ISA devices.
nullplan wrote:
I had the idea of hardcoding zones as well, but that felt wrong somehow. There is ISA DMA, which needs 24 bit physical addresses and blocks that do not cross a 64k boundary.
My physical memory allocator can support aligned addresses when allocating multiple pages, like 64 aligned. I can also allocate 2M pages.
nullplan wrote:
There is SMP initialization which requires a 20 bit address when done with the SIPI method (and a 64-bit address when done with the ACPI mailbox method).
I reserve fixed addresses for this.
nullplan wrote:
According to the Linux source code, some EHCI implementations have errata that say they do not work well with addresses above 2GB, so those need 31 bit addresses. Do I add another zone whenever a device comes along with a new weird requirement?
Plus, the zoning adds difficulties when confronted with a device that may use one or the other. As you admit when you say that you treat EHCI as a 32-bit device because the added code complexity is not worth it. With the method presented here, there are no zones, and the max address is a data item. So all devices can take advantage of all addresses (well, most of them. Again the thing with the 4GB page for the periodic list and all the QHs and TDs is just weird, and Linux will fix that page to zero, and I intend to do the same), so you do not run into a fragmentation issue where you have to return "no more memory" even though plenty is free, just not in your zone.
Actually, the main issue with EHCI is if Windows takes advantage of the 4G banking method. If it doesn't, chances are some EHCI chips are broken. The decision made in Linux points to some EHCI chips being broken.
You also need to separate the issue of QHs and TDs from the issue if you can map an external address to the queues, or if you need to allocate a new block below 4G and copy the buffer. If you have any physical address above 4G in the system, then the copy method must be used (unless you do it on a address-by-address basis).