On Fri, Apr 08, 2022, Joerg Roedel wrote: > On Wed, Apr 06, 2022 at 01:50:29AM +0000, Sean Christopherson wrote: > > On Thu, Feb 24, 2022, Varad Gautam wrote: > > > Using Linux's IOIO #VC processing logic. > > > > How much string I/O is there in KUT? I assume it's rare, i.e. avoiding it entirely > > is probably less work in the long run. > > The problem is that SEV-ES support will silently break if someone adds > it unnoticed and without testing changes on SEV-ES. But IMO that is extremely unlikely to happen. objdump + grep shows that the only string I/O in KUT comes from the explicit asm in emulator.c and amd_sev.c. And the existence of amd_sev.c's version suggests that emulator.c isn't supported. I.e. this is being added purely for an SEV specific test, which is silly. And it's not like we're getting validation coverage of the exit_info, that also comes from software in vc_ioio_exitinfo(). Burying this in the #VC handler makes it so much harder to understand what is actually be tested, and will make it difficult to test the more interesting edge cases. E.g. I'd really like to see a test that requests string I/O emulation for a buffer that's beyond the allowed size, straddles multiple pages, walks into non-existent memory, etc.., and doing those with a direct #VMGEXIT will be a lot easier to write and read then bouncing through the #VC handler.
