SmbusI801: Use MMIO instead of the IO ports

[Steve-Tech]

Hi, this PR switches SmbusI801 to use MMIO instead of the x86 I/O ports. This also drops support for southbridges older than the ICH8, due to lack of MMIO support.

This was inspired by this Linux kernel commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d50f2f5d51ea609194439e6e3f470d1a4fad761b

Hopefully, this will make i801 slightly more faster and efficient. Just testing with my old Python benchmark, the average time went from 711μs to 681μs (30μs faster) for I2C_SMBUS_BYTE_DATA.

Also, I've got 2 questions:

• I noticed the virtual_*_byte functions return a status; is it expected for them to fail, or is it okay to just ignore it?
• Should we drop the whole pci_devices array? There would still be a check for a vendor of 0x8086 (Intel), and the SMBus device class.

@Blacktempel what are your thoughts on MMIO?

Thanks,
Steve

[Blacktempel]

@Blacktempel what are your thoughts on MMIO?

As long as all DDR3+ memory modules can still be supported (also see #68) ?
I'm not too sure about ICH7.

I think this should be made optional like in the commit you referenced.

if available.

[Steve-Tech]

As long as all DDR3+ memory modules can still be supported

Alright, that's a fair enough target. Looks like there are a few ICH7 boards with DDR3, so I'll make it if available like Linux.

(also see #68)

Ahh cool, I might wait for that to be merged first, so this doesn't conflict and be a pain.

Thank you!

[namazso]

That other PR was merged.

When questioning support scope, feel free to use the Microsoft requirements for LTSC 1809, as that's the minimum PawnIO supports anyway: https://learn.microsoft.com/en-us/windows-hardware/design/minimum/supported/windows-10-ltsc-1809-supported-intel-processors

I am not too worried about dropping support for ancient stuff, users should not expect support on already vendor-unsupported setups.

[Steve-Tech]

Perfect! All of those CPUs look far newer than the Core 2 Duo era chips, so they should all be fine.

I also just wanna bring @namazso's attention to these 2 questions, if you've missed them:

• I noticed the virtual_*_byte functions return a status; is it expected for them to fail, or is it okay to just ignore it?
• Should we drop the whole pci_devices array? There would still be a check for a vendor of 0x8086 (Intel), and the SMBus device class.

[namazso]

I noticed the virtual_*_byte functions return a status; is it expected for them to fail, or is it okay to just ignore it?

Reading invalid nonpaged memory will just BSoD instead of reporting an error status, so in those cases it doesn't matter. For paged memory, it's a bit more complicated:

• Usermode memory may be freed by a malicious user, which would report access violation
• In general any paged memory, especially mapped files, may encounter disk IO error

I'd expect most (if not all) modules to only be dealing with nonpaged memory at most, so for those error handling is much less important.

Should we drop the whole pci_devices array? There would still be a check for a vendor of 0x8086 (Intel), and the SMBus device class.

I'm fine with that. As long as a failure mode can't lead to any useful vulnerability it's okay to skip checks. Preventing other failure modes, including hardware damage, is not a requirement. That's on the caller.

[Steve-Tech]

Epic! That all sounds good. It's a pain that there seems to be no other way to know for sure that this is a supported controller, but I feel you'd have to be super unlucky for this to damage hardware.

I'm happy for this to be merged, if you're happy with it.