linux-kernel - Re: [PATCH] KVM: Documentation: document how KVM is tested

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <844d7aeec492704bead16ebe163c908deaac8301.camel@intel.com>
Date: Thu, 10 Jul 2025 17:44:42 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
CC: "seanjc@...gle.com" <seanjc@...gle.com>
Subject: Re: [PATCH] KVM: Documentation: document how KVM is tested

On Thu, 2025-07-10 at 12:29 +0200, Paolo Bonzini wrote:
> +Bigger features, usually spanning host and guest
> +  These should be supported by Linux guests, with limited exceptions
> +  for Hyper-V features that are testable on Windows guests.  It is
> +  strongly suggested that the feature be usable exclusively with open
> +  source code, including in at least one of QEMU or crosvm.  Selftests

"be usable exclusively with open source code" might be a little ambiguous. I
think you mean should be usable without any closed source components. But, it
might be read that it should not be used with closed source components.

I think you also don't mean host firmware, etc.

Maybe clearer?
   It is strongly suggested that the feature be usable with a full stack of open
   source userspace and guest, including in at least one of QEMU or crosvm.

And thanks for clarifying the policy!

> +  should test at least API error cases.  Guest operation can be
> +  covered by either selftests of ``kvm-unit-tests`` (this is especially
> +  important for paravirtualized and Windows-only features).  Strong
> +  selftest coverage can also be a replacement for implementation in an
> +  open source VMM, but this is generally not recommended.
> +
> +Following the above suggestions for testing in selftests and
> +``kvm-unit-tests`` will make it easier for the maintainers to review
> +and accept your code.  In fact, even before you contribute your changes
> +upstream it will make it easier for you to develop for KVM.
> +
> +Of course, the KVM maintainers reserve the right to require more tests,
> +though they may also waive the requirement from time to time.