On Fri, Apr 15, 2022 at 9:57 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > 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. For the record, I like the current approach of implementing a #VC handler within kvm-unit-tests itself for the string IO. Rationale: - Makes writing string IO tests easy. - We get some level of testing of the #VC handler in the guest kernel in the sense that this #VC handler is based on that one. So if we find an issue in this handler we know we probably need to fix that same issue in the guest kernel #VC handler. - I don't follow the argument that having a direct #VMGEXIT in the test itself makes the test easerit to write and read. It's going to add a lot of extra code to the test that makes it hard to parse the actual string IO operations and expectations IMHO. - I agree that writing test cases to straddle multiple pages, walk into non-existent memory, etc. is an excellent idea. But I don't follow how exposing the test itself to the #VC exit makes this easier. Worst case, the kvm-unit-tests can be extended with some sort of helper to expose to the test the scratch buffer size and whether it's embedded in the GHCB or external.
