On Wed, Apr 06, 2022 at 01:37:02AM +0000, Sean Christopherson wrote: > Do we really need Linux's decoder for this? Linux needs a more robust decoder > because it has to deal with userspace crud, but KUT should have full control over > what code it encounters in a #VC handler, e.g. we should never have to worry about > ignore prefixes on a WRMSR. And looking at future patches, KUT is still looking > at raw opcode bytes, e.g. > > /* Is it a WRMSR? */ > exit_info_1 = (ctxt->insn.opcode.bytes[1] == 0x30) ? 1 : 0; > > and the giant switch in vc_ioio_exitinfo(). > > The decoder does bring a bit of cleanliness, but 2k+ lines of code that's likely > to get stale fairly quickly is going to be a maintenance burden. And we certainly > don't need things like VEX prefix handling :-) > > Do you happen to have data on how often each flavors of instructions is encountered? > E.g. can we get away with a truly minimal "decoder" by modifying select tests to > avoid hard-to-decode instructions? Or even patch them to do VMGEXIT directly? Is it really less pain to have this code in KUT than not having it? The code for the instruction decoder is maintained in the kernel source tree, and KUT just can pull in a new version if needed. I think it is much better to include this code than to work around its absence every time it is needed, even when it is capable of doing more than is needed in this context. Regards, -- Jörg Rödel jroedel@xxxxxxx SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
