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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 11/09/2026 3:50 pm, Ross Lagerwall wrote:
> 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.

Yeah, much better.  I'll swap this in on commit.

Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>