From intel arch manual 19.3:
'..16-bit ports should be aligned to even addresses (0, 2, 4, ...) so that all 16 bits can be transferred in a
single bus cycle. Likewise, 32-bit ports should be aligned to addresses that are multiples of four (0, 4, 8, ...). The
processor supports data transfers to unaligned ports, but there is a performance penalty because one or more
extra bus cycle must be used.'
I think I've even seen it suggested that a 32bit access to ffff might be
defined - although I'm not sure if that's legal.
I don't know how well defined it is from an Official Intel Bus Definition perspective, but on at least one 486-era core and one Pentium-era core it would wrap. So an inl(0xffff) would result in an inb(0xffff), inw(0), inb(3) showing up on the bus. I hit this as a bug in debugging a custom driver way too many years ago. The cores weren't from intel, but were AMD and/or some other third party (I don't recall which ones). I'd rate my surity of this knowledge as medium, so if there's some other resource that contradicts this, I'd tend to believe that source for this edge-case behavior.
Warner