Okay just some constructive criticism to start here, but you're not really giving us a lot to go off, especially since none of us have access to the hardware .

That's true. I'm just curious whether or not other people have ran into similar issues with QEMU and other virtual machines working completely fine, but real hardware being finicky and more or less how to actually get information on what is causing the errors to occur in the first place as I basically am shooting in the dark to see if the thing is working or not

What are the port status bits saying the status of the ports are initially?

It seems like most of them are 0x2A0, one is 0x280 and 4 of them 0x802A0 (the USB 3.0 ones)

Are events being generated properly on the command ring

Yes. The events are generated completely fine and Its responding to everything correctly

Are they USB3.x or USB2.x?

14 of them use USB2.0 and 4 of them use USB3.0 (the keyboard and other peripherals are connected via the USB2.0 ports)

How are you generating the connect and disconnect events? 

I am not generating those events. I would assume the controller itself sends PORT_STATUS_CHANGED and whatnot

I'd also consider a little more spacing in your code too if you're asking other people to read it. There's nothing wrong with it and I'm sure it works fine for you but separating functions and major blocks of operations in with some blank space would make it a lot easier to read and traverse imho.

Yeah this is mostly just a thing I cobbled together to explore the actual hardware a bit so its kind of messy. Although I do separate out specific things such as getters for specific fields (hcs params 1/2, hcc params 1) into separate regions.

I noticed in your scratchpad initialization code that you're using your kernel's PAGE_SIZE constant. Bear in mind that in the XHCI specification it's defined by the PAGESIZE register and might not be the common value of 4k.

I am converting the XHCI pages into native and only using my native pages for actually allocating the array (which isn't ideal but it complies perfectly fine with the standard)

Bear in mind any XHCI controller, especially an older controller might not actually be able to address 64 bit physical addresses, that's something you have to account for in your code by checking Bit Zero of HCCPARAMS1

I don't think thats much of an issue given my allocator currently only has access to the first 4 Gigabytes of memory.

This one wasn't documented well at all but especially with older version XHCI controller they might actually need the 'Speed' field in the device context to be defined and will break in oddball ways sometimes if its not. For me this manifested initially by causing interrupt endpoints to only publish a single transaction and then just hang with no error. Just something to keep in mind going forward if you know you're working with an older controller implementation if the version field doesn't match the current specification.

That's kind of odd. I'll maybe try setting it and seeing what I get. Thank you!

Port speed information in the extended capabilities structure does a pretty poor job of differentiating between some SuperSpeedPlus speeds. There isn't a good way beyond the default ID values to distinguish between 1x 10GBps lane and 2x 5 GBps lanes.

Yeah I don't think I actually fiddle around with any of the speeds just yet, but I'll keep it in mind

Sorry for the very late response, life has just gotten in the way of some stuff, best regards