Re: [kvm-unit-tests PATCH v3 3/4] x86/access: Forced emulation support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04.04.23 18:36, Sean Christopherson wrote:
> On Tue, Apr 04, 2023, Mathias Krause wrote:
>> Testing bare metal on a NUC12 (i7-1260P) with kvm.ko loaded with
>> force_emulation_prefix=1 and not excluding AC_FEP_BIT from ac_test_bump()
>> gives me a runtime of little over 41s with EPT enabled and, funnily, only 9s
>> with EPT disabled, as that implicitly excludes the CR4.PKE tests, reducing
>> the number of tests to run by a factor of 10 (~38 million tests down do 3.8
>> million).
> 
> Ah, right, fancy new features.  Running on an Icelake, i.e. with 5-level paging
> and PKRU support, is indeed quite painful.

Jepp.

> 
> After much fiddling, I think the best option is to add a separate config entry
> to enable FEP, and have that entry be nodefault, i.e. a "manual" testcase.  Ditto
> for the nVMX #PF variant.  That will allow CI and other runners to enable the
> test for compatible configs, e.g. when running on bare metal, without causing
> problems for existing setups.  Well, unless there are setups that do a generic
> "-g nodefault", but x86 doesn't currently have any nodefault tests so that's
> quite unlikely.

Yeah, that works too. I was also thinking of a commandline parameter to
allow ac_test_bump() to take the FEP bit into account to allow testing
forced emulation, but not by default.

> 
> The only downside is that the CR0.WP testcase will also become manual only.  We
> could obviously have it ignore the opt-in flag, but there's value is containing
> it to the opt-in testcase, e.g. it becomes very obvious that emulation is relevant
> to the failure when the FEP version fails but the non-FEP version does not.

Well, I think there's much more value in doing the CR0.WP emulation
tests by default than there is to bind them to the "manual" test.
They're fast, only two accesses, so runtime is no argument here. They
also test an important aspects of KVM's MMU role, so we shouldn't bury
these behind a "nodefault" flag.

I'd rather see the command line option be a toggle for the access bits
permutation test only, which are dog slow with forced emulation.

>  And
> I also think we should mark the VPID-based variants nodefault, as they have 4+
> minute runtimes in VMs, i.e. we should encourage use of "-g nodefault" in CI when
> appropriate.

Ok, no objection from my side, as I have no dog in that fight ;)

> 
> I'll post a v4, there are other cleanups needed in the access test, e.g. the darn
> thing doesn't use report_summary() and so actually getting it to report a SKIP is
> impossible.

I think that's just because it's such an old test that predates the
reporting infrastructure. But yeah, it could get some spring cleanup,
like dropping the #defines for true and false ;)

Thanks,
Mathias



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux