Re: [PATCH v2] nestedsvm: Fix multi-byte IO port intercept check

[Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>]

On 9/11/26 2:36 PM, Andrew Cooper wrote:
> On 11/09/2026 2:23 pm, Ross Lagerwall wrote:
> > For multi-byte IO port accesses, the APM says that SVM should intercept
> > if any of the corresponding permission bits are set. However, the code
> > has this backwards and only intercepts if all the permission bits are
> > set. Fix this and at the same time, make things safer by handling
> > mapping failures as intercepted. Also rename the 'enabled' variable to
> > make it clearer what it does.
> >
> > This affects Hyper-V since it does not generally set all the permission
> > bits of the multi-byte ports it allows its root partition to access.
> > This results in an L2 root partition that cannot do PCI config space
> > accesses and therefore cannot access its NVMe disk to continue booting.
> >
> > Signed-off-by: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
> The reason I asked about 0xcf9 is because it's the one-byte PCH reset
> register, which hides fully inside the normal 4 bytes at 0xcf8 for CFG
> accesses.
>
> Despite outward appearances, the x86 IO space is not one uniform space.
> It's 3 orthogonal space (1,2 and 4-byte accesses) where the target
> device gets to choose whether muti-byte values alias in the spaces, or
> are entirely disjoint.
>
> For the HyperV root partition specifically, I'd expect 0xcf9 to be
> unintercepted so as not to interfere with the final steps of
> shutdown/reboot from the main kernel.
>
> The patch looks ok, but I think the second paragraph needs a bit more
> explaining.  Are we saying that because 0xcf9 was permitted, we allowed
> 4b@0xcf8 to be permitted, changing L1's CFG index rather than changing
> L2's CFG index, causing the subsequent 0xcfc access to produce garbage?
Yes. The incorrect trace shows:

L2 write 4b@0xcf8, permitted so it updates the L1 CFG index
L2 read  2b@0xcfc, VMEXITs to L1
L1 write 4b@0xcf8, updates the L1 CFG index to the wrong value (since it didn't
see the first L2 write)
L1 read  2b@0xcf8, reads the incorrect value from the device model in L0

How about this for the second paragraph?

This affects Hyper-V which for the root partition intercepts 0xcf8 and
0xcfc-0xcff. L2 issues 4 byte CFG index writes to 0xcf8 which are incorrectly
permitted and update the L1 CFG index. The subsequent L2 CFG data read at 0xcfc
is intercepted by L1, then resubmitted as a CFG index write followed by CFG
data read to L0. Since L1 doesn't see the CFG index write by L2, it uses the
wrong index and gets garbage back, ultimately leading to a failure to boot
since it cannot access its NVMe disk.

Ross