Re: [GIT PULL] Modules changes for v6.13-rc1

On Wed, Nov 27, 2024 at 03:56:48PM -0800, Linus Torvalds wrote: > On Wed, 27 Nov 2024 at 15:26, Luis Chamberlain wrote: > > > > On Wed, Nov 27, 2024 at 02:35:36PM -0800, Luis Chamberlain wrote: > > > Sorry about that, I'm on it. > > > > OK here is a fix, goes double build tested and then run time

[PATCH v3 27/57] KVM: x86: #undef SPEC_CTRL_SSBD in cpuid.c to avoid macro collisions

Undefine SPEC_CTRL_SSBD, which is #defined by msr-index.h to represent the enable flag in MSR_IA32_SPEC_CTRL, to avoid issues with the macro being unpacked into its raw value when passed to KVM's F() macro. This will allow using multiple layers of macros in F() and friends, e.g. to harden against

Re: [GIT PULL] Modules changes for v6.13-rc1

On Thu, Nov 28, 2024 at 11:42 AM Luis Chamberlain wrote: > > Now with Masahiro's cleanups, in my testing we don't need the FORCE anymore. > > > From 83497e0e83d81950df54d82461b1dae629842147 Mon Sep 17 00:00:00 2001 > From: Luis Chamberlain > Date: Wed, 27 Nov 2024 14:10:57 -0800 > Subject: [PATCH

Re: [PATCH] virtio_net: drain unconsumed tx completions if any before dql_reset

On Wed, Nov 27, 2024 at 12:08 PM Koichiro Den wrote: > > On Wed, Nov 27, 2024 at 11:24:15AM +0800, Jason Wang wrote: > > On Tue, Nov 26, 2024 at 12:44 PM Koichiro Den > > wrote: > > > > > > On Tue, Nov 26, 2024 at 11:50:17AM +0800, Jason Wang wrote: > > > > On Tue, Nov 26, 2024 at 10:42 AM Koichi

Re: [GIT PULL] Modules changes for v6.13-rc1

On Thu, Nov 28, 2024 at 11:22 AM Luis Chamberlain wrote: > > On Wed, Nov 27, 2024 at 03:56:48PM -0800, Linus Torvalds wrote: > > On Wed, 27 Nov 2024 at 15:26, Luis Chamberlain wrote: > > > > > > On Wed, Nov 27, 2024 at 02:35:36PM -0800, Luis Chamberlain wrote: > > > > Sorry about that, I'm on it.

Re: [GIT PULL] Modules changes for v6.13-rc1

On Thu, Nov 28, 2024 at 11:38 AM Luis Chamberlain wrote: > > On Thu, Nov 28, 2024 at 11:09:43AM +0900, Masahiro Yamada wrote: > > diff --git a/lib/tests/module/Makefile b/lib/tests/module/Makefile > > index af5c27b996cb..8cfc4ae600a9 100644 > > --- a/lib/tests/module/Makefile > > +++ b/lib/tests/m

[PATCH v3 20/57] KVM: x86: Do reverse CPUID sanity checks in __feature_leaf()

Do the compile-time sanity checks on reverse_cpuid in __feature_leaf() so that higher level APIs don't need to "manually" perform the sanity checks. No functional change intended. Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson --- arch/x86/kvm/cpuid.h | 3 --- arch/x86/

[PATCH v3 22/57] KVM: x86: Unpack F() CPUID feature flag macros to one flag per line of code

Refactor kvm_set_cpu_caps() to express each supported (or not) feature flag on a separate line, modulo a handful of cases where KVM does not, and likely will not, support a sequence of flags. This will allow adding fancier macros with longer, more descriptive names without resulting in absurd line

[PATCH v3 19/57] KVM: x86: Don't update PV features caches when enabling enforcement capability

Revert the chunk of commit 01b4f510b9f4 ("kvm: x86: ensure pv_cpuid.features is initialized when enabling cap") that forced a PV features cache refresh during KVM_CAP_ENFORCE_PV_FEATURE_CPUID, as whatever ioctl() ordering issue it alleged to have fixed never existed upstream, and likely never exist

[PATCH v3 21/57] KVM: x86: Account for max supported CPUID leaf when getting raw host CPUID

Explicitly zero out the feature word in kvm_cpu_caps if the word's associated CPUID function is greater than the max leaf supported by the CPU. For such unsupported functions, Intel CPUs return the output from the last supported leaf, not all zeros. Practically speaking, this is likely a benign b

[PATCH v3 18/57] KVM: x86: Zero out PV features cache when the CPUID leaf is not present

Clear KVM's PV feature cache prior when processing a new guest CPUID so that KVM doesn't keep a stale cache entry if userspace does KVM_SET_CPUID2 multiple times, once with a PV features entry, and a second time without. Fixes: 66570e966dd9 ("kvm: x86: only provide PV features if enabled in guest'

[PATCH v3 15/57] KVM: x86: Drop the now unused KVM_X86_DISABLE_VALID_EXITS

Drop the KVM_X86_DISABLE_VALID_EXITS definition, as it is misleading, and unused in KVM *because* it is misleading. The set of exits that can be disabled is dynamic, i.e. userspace (and KVM) must check KVM's actual capabilities. Suggested-by: Xiaoyao Li Signed-off-by: Sean Christopherson --- i

[PATCH v3 23/57] KVM: x86: Rename kvm_cpu_cap_mask() to kvm_cpu_cap_init()

Rename kvm_cpu_cap_mask() to kvm_cpu_cap_init() in anticipation of merging it with kvm_cpu_cap_init_kvm_defined(), and in anticipation of _setting_ bits in the helper (a future commit will play macro games to set emulated feature flags via kvm_cpu_cap_init()). No functional change intended. Revie

[PATCH v3 26/57] KVM: x86: Handle kernel- and KVM-defined CPUID words in a single helper

Merge kvm_cpu_cap_init() and kvm_cpu_cap_init_kvm_defined() into a single helper. The only advantage of separating the two was to make it somewhat obvious that KVM directly initializes the KVM-defined words, whereas using a common helper will allow for hardening both kernel- and KVM-defined CPUID

[PATCH v3 25/57] KVM: x86: Add a macro to precisely handle aliased 0x1.EDX CPUID features

Add a macro to precisely handle CPUID features that AMD duplicated from CPUID.0x1.EDX into CPUID.0x8000_0001.EDX. This will allow adding an assert that all features passed to kvm_cpu_cap_init() match the word being processed, e.g. to prevent passing a feature from CPUID 0x7 to CPUID 0x1. Because

[PATCH v3 24/57] KVM: x86: Add a macro to init CPUID features that are 64-bit only

Add a macro to mask-in feature flags that are supported only on 64-bit kernels/KVM. In addition to reducing overall #ifdeffery, using a macro will allow hardening the kvm_cpu_cap initialization sequences to assert that the features being advertised are indeed included in the word being initialized

[PATCH v3 32/57] KVM: x86: Clear PV_UNHALT for !HLT-exiting only when userspace sets CPUID

Now that KVM disallows disabling HLT-exiting after vCPUs have been created, i.e. now that it's impossible for kvm_hlt_in_guest() to change while vCPUs are running, apply KVM's PV_UNHALT quirk only when userspace is setting guest CPUID. Opportunistically rename the helper to make it clear that KVM'

[PATCH v3 30/57] KVM: x86: Add a macro to init CPUID features that KVM emulates in software

Now that kvm_cpu_cap_init() is a macro with its own scope, add EMUL_F() to OR-in features that KVM emulates in software, i.e. that don't depend on the feature being available in hardware. The contained scope of kvm_cpu_cap_init() allows using a local variable to track the set of emulated leaves, w

[PATCH v3 28/57] KVM: x86: Harden CPU capabilities processing against out-of-scope features

Add compile-time assertions to verify that usage of F() and friends in kvm_set_cpu_caps() is scoped to the correct CPUID word, e.g. to detect bugs where KVM passes a feature bit from word X into word y. Add a one-off assertion in the aliased feature macro to ensure that only word 0x8000_0001.EDX a

[PATCH v3 31/57] KVM: x86: Swap incoming guest CPUID into vCPU before massaging in KVM_SET_CPUID2

When handling KVM_SET_CPUID{,2}, swap the old and new CPUID arrays and lengths before processing the new CPUID, and simply undo the swap if setting the new CPUID fails for whatever reason. To keep the diff reasonable, continue passing the entry array and length to most helpers, and defer the more

[PATCH v3 33/57] KVM: x86: Remove unnecessary caching of KVM's PV CPUID base

Now that KVM only searches for KVM's PV CPUID base when userspace sets guest CPUID, drop the cache and simply do the search every time. Practically speaking, this is a nop except for situations where userspace sets CPUID _after_ running the vCPU, which is anything but a hot path, e.g. QEMU does so

[PATCH v3 29/57] KVM: x86: Add a macro to init CPUID features that ignore host kernel support

Add a macro for use in kvm_set_cpu_caps() to automagically initialize features that KVM wants to support based solely on the CPU's capabilities, e.g. KVM advertises LA57 support if it's available in hardware, even if the host kernel isn't utilizing 57-bit virtual addresses. Track a features that a

[PATCH v3 56/57] KVM: x86: Explicitly track feature flags that are enabled at runtime

Add one last (hopefully) CPUID feature macro, RUNTIME_F(), and use it to track features that KVM supports, but that are only set at runtime (in response to other state), and aren't advertised to userspace via KVM_GET_SUPPORTED_CPUID. Currently, RUNTIME_F() is mostly just documentation, but trackin

[PATCH v3 52/57] KVM: x86: Add a macro for features that are synthesized into boot_cpu_data

Add yet another CPUID macro, this time for features that the host kernel synthesizes into boot_cpu_data, i.e. that the kernel force sets even in situations where the feature isn't reported by CPUID. Thanks to the macro shenanigans of kvm_cpu_cap_init(), such features can now be handled in the core

[PATCH] selftests/x86: Fix the wrong format specifier

Both 'iterations' and 'num_threads' are unsigned int types, so the output format should be %u. Signed-off-by: liujing diff --git a/tools/testing/selftests/x86/amx.c b/tools/testing/selftests/x86/amx.c index 1fdf35a4d7f6..b64ba55c9019 100644 --- a/tools/testing/selftests/x86/amx.c +++ b/tools/te

Re: [PATCH v14 4/8] remoteproc: Rename load() operation to load_segments() in rproc_ops struct

Hi Arnaud, kernel test robot noticed the following build errors: [auto build test ERROR on adc218676eef25575469234709c2d87185ca223a] url: https://github.com/intel-lab-lkp/linux/commits/Arnaud-Pouliquen/remoteproc-core-Introduce-rproc_pa_to_va-helper/20241128-094434 base: adc218676eef255754

[PATCH] selftests/timens: Add fclose(proc) to prevent memory leaks

If fopen succeeds, the fscanf function is called to read the data. Regardless of whether fscanf is successful, you need to run fclose(proc) to prevent memory leaks. Signed-off-by: liujing diff --git a/tools/testing/selftests/timens/procfs.c b/tools/testing/selftests/timens/procfs.c index 1833ca

Re: [GIT PULL] Modules changes for v6.13-rc1

On Tue, 26 Nov 2024 at 17:10, Luis Chamberlain wrote: > > Highlights for this merge window: Lowlights: > * Adds a new modules selftests: kallsyms which helps us tests find_symbol() > and the limits of kallsyms on Linux today. This is completely broken. Try doing "make allmodconfig" and t

Re: [GIT PULL] virtio: features, fixes, cleanups

The pull request you sent on Tue, 26 Nov 2024 16:31:44 -0500: > https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2a50b1e766a09f1a2da5f291956b8dceb58b5d54 Thank you! -- Deet-doot-dot, I am a b

Re: [GIT PULL] Modules changes for v6.13-rc1

On Wed, Nov 27, 2024 at 01:22:37PM -0800, Linus Torvalds wrote: > On Tue, 26 Nov 2024 at 17:10, Luis Chamberlain wrote: > > > > Highlights for this merge window: > > Lowlights: > > > * Adds a new modules selftests: kallsyms which helps us tests > > find_symbol() > > and the limits of kall

[PATCH net v3 2/2] selftests: drv-net: rss_ctx: Add test for ntuple rule

Extend the rss_ctx test suite to test that an ntuple action that redirects to an RSS context contains that information in `ethtool -n`. Otherwise the output from ethtool is highly deceiving. This test helps ensure drivers are compliant with the API. Signed-off-by: Daniel Xu --- tools/testing/sel

[PATCH net v3 0/2] bnxt: Fix failure to report RSS context in ntuple rule

This patchset fixes a bug where bnxt driver was failing to report that an ntuple rule is redirecting to an RSS context. First commit is the fix, then second commit extends selftests to detect if other/new drivers are compliant with ntuple/rss_ctx API. === Changelog === Changes from v2: * Rebase t

Re: drivers/virtio/virtio_ring.c:1162:11: error: 'struct vring_virtqueue' has no member named 'premapped'

On Wed, 27 Nov 2024 13:30:59 +0530, Naresh Kamboju wrote: > The following build errors were noticed for arm64, arm, x86_64 and riscv. > > First seen on Sasha Linus-next 441d2975754ad94f3ce2e29f672824bc2dc5120c. > Good: 07e98e730a08081b6d0b5c3a173b0487c36ed27f > Bad: 441d2975754ad94f3ce2e29f6

Re: [GIT PULL] Modules changes for v6.13-rc1

On Thu, Nov 28, 2024 at 12:02 PM Luis Chamberlain wrote: > > On Thu, Nov 28, 2024 at 11:56:44AM +0900, Masahiro Yamada wrote: > > On Thu, Nov 28, 2024 at 11:42 AM Luis Chamberlain wrote: > > > > > > Now with Masahiro's cleanups, in my testing we don't need the FORCE > > > anymore. > > > > > > >

Re: [GIT PULL] Modules changes for v6.13-rc1

On Thu, Nov 28, 2024 at 12:10 PM Luis Chamberlain wrote: > > On Wed, Nov 27, 2024 at 07:02:55PM -0800, Luis Chamberlain wrote: > > I did. Multiple times. > > I've split this up now in 2 parts, one with your fixes and then the > other boundary fixes which are not related. > > From 8e4c903fa3079e1c0

Re: [GIT PULL] Modules changes for v6.13-rc1

On Wed, Nov 27, 2024 at 07:02:55PM -0800, Luis Chamberlain wrote: > I did. Multiple times. I've split this up now in 2 parts, one with your fixes and then the other boundary fixes which are not related. >From 8e4c903fa3079e1c05c9585f78c57e8067024d99 Mon Sep 17 00:00:00 2001 From: Luis Chamberlain

[PATCH] selftests: prctl: Fix resource leaks

After using the fopen function successfully, you need to call fclose to close the file before finally returning. Signed-off-by: liujing diff --git a/tools/testing/selftests/prctl/set-process-name.c b/tools/testing/selftests/prctl/set-process-name.c index 562f707ba771..7be7afff0cd2 100644 --- a/

Re: [PATCH] selftest: hugetlb_dio: Fix test naming

allocation : %d\n", > free_hpage_b); > - ksft_print_msg("No. Free pages after munmap : %d\n", > free_hpage_a); > - ksft_test_result_pass(": Huge pages freed successfully !\n"); > - } > + ksft_test_result(free_hpage_a == free_h

[PATCH v5 3/3] selftests/lam: Test get_user() LAM pointer handling

Recent change in how get_user() handles pointers [1] has a specific case for LAM. It assigns a different bitmask that's later used to check whether a pointer comes from userland in get_user(). Add test case to LAM that utilizes a ioctl (FIOASYNC) syscall which uses get_user() in its implementation

Re: [PATCH 2/2] selftests/exec: add a test for execveat()'s comm

On Wed, Nov 27, 2024 at 02:25:29PM +, Mark Brown wrote: > On Wed, Oct 30, 2024 at 02:37:32PM -0600, Tycho Andersen wrote: > > From: Tycho Andersen > > > > In the previous patch we've defined a couple behaviors: > > > > 1. execveat(fd, AT_EMPTY_PATH, {"foo"}, ...) should render argv[0] as > >

Re: [PATCH] selftests/damon: Add _damon_sysfs.py to TEST_FILES

On Wed, 27 Nov 2024 12:08:53 + Maximilian Heyne wrote: > When running selftests I encountered the following error message with > some damon tests: > > # Traceback (most recent call last): > # File "[...]/damon/./damos_quota.py", line 7, in > # import _damon_sysfs > # ModuleNotFoun

Re: [PATCH 2/2] selftests/exec: add a test for execveat()'s comm

On Wed, Oct 30, 2024 at 02:37:32PM -0600, Tycho Andersen wrote: > From: Tycho Andersen > > In the previous patch we've defined a couple behaviors: > > 1. execveat(fd, AT_EMPTY_PATH, {"foo"}, ...) should render argv[0] as >/proc/pid/comm > 2. execveat(fd, AT_EMPTY_PATH, {NULL}, ...) should ke

[PATCH v5 2/3] selftests/lam: Skip test if LAM is disabled

Until LASS is merged into the kernel [1], LAM is left disabled in the config file. Running the LAM selftest with disabled LAM only results in unhelpful output. Use one of LAM syscalls() to determine whether the kernel was compiled with LAM support (CONFIG_ADDRESS_MASKING) or not. Skip running the

[PATCH v5 0/3] selftests/lam: get_user additions and LAM enabled check

Recent change in how get_user() handles pointers [1] has a specific case for LAM. It assigns a different bitmask that's later used to check whether a pointer comes from userland in get_user(). While currently commented out (until LASS [2] is merged into the kernel) it's worth making changes to the

[PATCH v5 1/3] selftests/lam: Move cpu_has_la57() to use cpuinfo flag

In current form cpu_has_la57() reports platform's support for LA57 through reading the output of cpuid. A much more useful information is whether 5-level paging is actually enabled on the running system. Presence of the la57 flag in /proc/cpuinfo signifies that 5-level paging was compiled into the

Re: [PATCH 2/2] selftests/exec: add a test for execveat()'s comm

On Wed, Nov 27, 2024 at 08:00:12AM -0700, Tycho Andersen wrote: > On Wed, Nov 27, 2024 at 02:25:29PM +, Mark Brown wrote: > > This test doesn't pass in my CI, running on an i.MX8MP Verdin board. > > This is an arm64 system and I'm running the tests on NFS. > Strange... but this series has bee

Re: [PATCH] kmod: verify module name before invoking modprobe

On 11/20/24 03:17, Song Chen wrote: > Hi Petr, > > 在 2024/11/18 20:54, Petr Pavlu 写道: >> On 11/13/24 03:15, Song Chen wrote: >>> 在 2024/11/12 20:56, Petr Pavlu 写道: On 11/10/24 12:42, Song Chen wrote: > Sometimes when kernel calls request_module to load a module > into kernel space, it

Re: [PATCH v4 0/3] selftests/lam: get_user additions and LAM enabled check

On 2024-11-26 at 09:34:36 -0700, Shuah Khan wrote: >On 11/26/24 06:34, Maciej Wieczor-Retman wrote: >> Recent change in how get_user() handles pointers [1] has a specific case >> for LAM. It assigns a different bitmask that's later used to check >> whether a pointer comes from userland in get_user(

Re: [GIT PULL] Modules changes for v6.13-rc1

The pull request you sent on Tue, 26 Nov 2024 17:10:32 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/ > tags/modules-6.13-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b5361254c9027c2b3730be1bebcdb37eed42e9a5 Thank you! -- Deet-doot-

Re: [RFC PATCH 1/3] module: Split module_enable_rodata_ro()

On Wed, Nov 27, 2024 at 02:37:40PM +0100, Christophe Leroy wrote: > > > Le 26/11/2024 à 20:58, Luis Chamberlain a écrit : > > On Sat, Nov 09, 2024 at 11:35:35AM +0100, Christophe Leroy wrote: > > > module_enable_rodata_ro() is called twice, once before module init > > > to set rodata sections rea

[PATCH v1] selftests: ktap_helpers: Fix uninitialized variable

__ktap_test() may be called without the optional third argument which is an issue for scripts using `set -u` to detect uninitialized variables and potential bugs. Fix this optional "directive" argument by either using the third argument or an empty string. This was discovered while developing tes

Re: [PATCH v1] selftests: ktap_helpers: Fix uninitialized variable

On Wed, Nov 27, 2024 at 05:03:40PM +0100, Mickaël Salaün wrote: > __ktap_test() may be called without the optional third argument which is > an issue for scripts using `set -u` to detect uninitialized variables > and potential bugs. > > Fix this optional "directive" argument by either using the th

[PATCH] selftest: hugetlb_dio: Fix test naming

free_hpage_b, +"free huge pages from %u-%u\n", start_off, end_off); } int main(void) --- base-commit: 6f3d2b5299b0a8bcb8a9405a8d3fceb24f79c4f0 change-id: 20241127-kselftest-mm-hugetlb-dio-names-1ebccbe8183d Best regards, -- Mark Brown

Re: [GIT PULL] Modules changes for v6.13-rc1

On Wed, Nov 27, 2024 at 02:35:36PM -0800, Luis Chamberlain wrote: > Sorry about that, I'm on it. OK here is a fix, goes double build tested and then run time tested. >From 6c9ef19d7676c3f650f1de3e2619c958f21c0b75 Mon Sep 17 00:00:00 2001 From: Luis Chamberlain Date: Wed, 27 Nov 2024 14:10:57 -08

Re: [GIT PULL] Modules changes for v6.13-rc1

On Wed, 27 Nov 2024 at 15:26, Luis Chamberlain wrote: > > On Wed, Nov 27, 2024 at 02:35:36PM -0800, Luis Chamberlain wrote: > > Sorry about that, I'm on it. > > OK here is a fix, goes double build tested and then run time tested. No, you misunderstand. I don't mind the tests being built. That's

[PATCH v3 00/57] KVM: x86: CPUID overhaul, fixes, and caching

The super short TL;DR: snapshot all X86_FEATURE_* flags that KVM cares about so that all queries against guest capabilities are "fast", e.g. don't require manual enabling or judgment calls as to where a feature needs to be fast. The guest_cpu_cap_* nomenclature follows the existing kvm_cpu_cap_* e

[PATCH v3 03/57] KVM: x86: Do all post-set CPUID processing during vCPU creation

During vCPU creation, process KVM's default, empty CPUID as if userspace set an empty CPUID to ensure consistent and correct behavior with respect to guest CPUID. E.g. if userspace never sets guest CPUID, KVM will never configure cr4_guest_rsvd_bits, and thus create divergent, incorrect, guest- vi

[PATCH v3 02/57] KVM: x86: Limit use of F() and SF() to kvm_cpu_cap_{mask,init_kvm_defined}()

Define and undefine the F() and SF() macros precisely around kvm_set_cpu_caps() to make it all but impossible to use the macros outside of kvm_cpu_cap_{mask,init_kvm_defined}(). Currently, F() is a simple passthrough, but SF() is actively dangerous as it checks that the scattered feature is suppor

[PATCH v3 04/57] KVM: x86: Explicitly do runtime CPUID updates "after" initial setup

Explicitly perform runtime CPUID adjustments as part of the "after set CPUID" flow to guard against bugs where KVM consumes stale vCPU/CPUID state during kvm_update_cpuid_runtime(). E.g. see commit 4736d85f0d18 ("KVM: x86: Use actual kvm_cpuid.base for clearing KVM_FEATURE_PV_UNHALT"). Whacking e

[PATCH v3 01/57] KVM: x86: Use feature_bit() to clear CONSTANT_TSC when emulating CPUID

When clearing CONSTANT_TSC during CPUID emulation due to a Hyper-V quirk, use feature_bit() instead of SF() to ensure the bit is actually cleared. SF() evaluates to zero if the _host_ doesn't support the feature. I.e. KVM could keep the bit set if userspace advertised CONSTANT_TSC despite it not b

[PATCH v3 06/57] KVM: selftests: Update x86's set_sregs_test to match KVM's CPUID enforcement

Rework x86's set sregs test to verify that KVM enforces CPUID vs. CR4 features even if userspace hasn't explicitly set guest CPUID. KVM used to allow userspace to set any KVM-supported CR4 value prior to KVM_SET_CPUID2, and the test verified that behavior. However, the testcase was written purely

[PATCH v3 07/57] KVM: selftests: Assert that vcpu->cpuid is non-NULL when getting CPUID entries

Add a sanity check in __vcpu_get_cpuid_entry() to provide a friendlier error than a segfault when a test developer tries to use a vCPU CPUID helper on a barebones vCPU. Signed-off-by: Sean Christopherson --- tools/testing/selftests/kvm/include/x86_64/processor.h | 2 ++ 1 file changed, 2 inserti

[PATCH v3 05/57] KVM: x86: Account for KVM-reserved CR4 bits when passing through CR4 on VMX

Drop x86.c's local pre-computed cr4_reserved bits and instead fold KVM's reserved bits into the guest's reserved bits. This fixes a bug where VMX's set_cr4_guest_host_mask() fails to account for KVM-reserved bits when deciding which bits can be passed through to the guest. In most cases, letting

[PATCH v3 11/57] KVM: x86/pmu: Drop now-redundant refresh() during init()

Drop the manual kvm_pmu_refresh() from kvm_pmu_init() now that kvm_arch_vcpu_create() performs the refresh via kvm_vcpu_after_set_cpuid(). Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson --- arch/x86/kvm/pmu.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/x86/kvm/pmu.c

[PATCH v3 12/57] KVM: x86: Drop now-redundant MAXPHYADDR and GPA rsvd bits from vCPU creation

Drop the manual initialization of maxphyaddr and reserved_gpa_bits during vCPU creation now that kvm_arch_vcpu_create() unconditionally invokes kvm_vcpu_after_set_cpuid(), which handles all such CPUID caching. None of the helpers between the existing code in kvm_arch_vcpu_create() and the call to

[PATCH v3 08/57] KVM: selftests: Refresh vCPU CPUID cache in __vcpu_get_cpuid_entry()

Refresh selftests' CPUID cache in the vCPU structure when querying a CPUID entry so that tests don't consume stale data when KVM modifies CPUID as a side effect to a completely unrelated change. E.g. KVM adjusts OSXSAVE in response to CR4.OSXSAVE changes. Unnecessarily invoking KVM_GET_CPUID is s

[PATCH v3 13/57] KVM: x86: Disallow KVM_CAP_X86_DISABLE_EXITS after vCPU creation

Reject KVM_CAP_X86_DISABLE_EXITS if vCPUs have been created, as disabling PAUSE/MWAIT/HLT exits after vCPUs have been created is broken and useless, e.g. except for PAUSE on SVM, the relevant intercepts aren't updated after vCPU creation. vCPUs may also end up with an inconsistent configuration if

[PATCH v3 10/57] KVM: x86: Move __kvm_is_valid_cr4() definition to x86.h

Let vendor code inline __kvm_is_valid_cr4() now x86.c's cr4_reserved_bits no longer exists, as keeping cr4_reserved_bits local to x86.c was the only reason for "hiding" the definition of __kvm_is_valid_cr4(). No functional change intended. Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christop

[PATCH v3 09/57] KVM: selftests: Verify KVM stuffs runtime CPUID OS bits on CR4 writes

Extend x86's set sregs test to verify that KVM sets/clears OSXSAVE and OSKPKE according to CR4.XSAVE and CR4.PKE respectively. For performance reasons, KVM is responsible for emulating the architectural behavior of the OS CPUID bits tracking CR4. Reviewed-by: Maxim Levitsky Signed-off-by: Sean C

[PATCH v3 14/57] KVM: x86: Reject disabling of MWAIT/HLT interception when not allowed

Reject KVM_CAP_X86_DISABLE_EXITS if userspace attempts to disable MWAIT or HLT exits and KVM previously reported (via KVM_CHECK_EXTENSION) that disabling the exit(s) is not allowed. E.g. because MWAIT isn't supported or the CPU doesn't have an always-running APIC timer, or because KVM is configure

[PATCH v3 16/57] KVM: selftests: Fix a bad TEST_REQUIRE() in x86's KVM PV test

Actually check for KVM support for disabling HLT-exiting instead of effectively checking that KVM_CAP_X86_DISABLE_EXITS is #defined to a non-zero value, and convert the TEST_REQUIRE() to a simple return so that only the sub-test is skipped if HLT-exiting is mandatory. The goof has likely gone unno

[PATCH v3 17/57] KVM: selftests: Update x86's KVM PV test to match KVM's disabling exits behavior

Rework x86's KVM PV features test to align with KVM's new, fixed behavior of not allowing userspace to disable HLT-exiting after vCPUs have been created. Rework the core testcase to disable HLT-exiting before creating a vCPU, and opportunistically modify keep the paired VM+vCPU creation to verify

Re: [GIT PULL] Modules changes for v6.13-rc1

On Thu, Nov 28, 2024 at 11:09:43AM +0900, Masahiro Yamada wrote: > diff --git a/lib/tests/module/Makefile b/lib/tests/module/Makefile > index af5c27b996cb..8cfc4ae600a9 100644 > --- a/lib/tests/module/Makefile > +++ b/lib/tests/module/Makefile > @@ -3,13 +3,12 @@ obj-$(CONFIG_TEST_KALLSYMS_B) += te

Re: [GIT PULL] Modules changes for v6.13-rc1

Now with Masahiro's cleanups, in my testing we don't need the FORCE anymore. >From 83497e0e83d81950df54d82461b1dae629842147 Mon Sep 17 00:00:00 2001 From: Luis Chamberlain Date: Wed, 27 Nov 2024 14:10:57 -0800 Subject: [PATCH v3] selftests: kallsyms: fix double build stupidity Fix the stupid FO

Re: [PATCH] selftest: hugetlb_dio: Fix test naming

for Direct I/O (DIO). If I understand correctly,|start_off| and|end_off| are not free huge pages but rather DIO buffer offsets. Should we change this message to "Hugetlb DIO buffer offset"? Thanks Donet } int main(void) --- base-commit: 6f3d2b5299b0a8bcb8a9405a8d3fceb24f79c4f0 change-id: 20241127-kselftest-mm-hugetlb-dio-names-1ebccbe8183d Best regards,

[PATCH v3 34/57] KVM: x86: Always operate on kvm_vcpu data in cpuid_entry2_find()

Now that KVM sets vcpu->arch.cpuid_{entries,nent} before processing the incoming CPUID entries during KVM_SET_CPUID{,2}, drop the @entries and @nent params from cpuid_entry2_find() and unconditionally operate on the vCPU state. No functional change intended. Reviewed-by: Maxim Levitsky Signed-of

[PATCH v3 36/57] KVM: x86: Remove all direct usage of cpuid_entry2_find()

Convert all use of cpuid_entry2_find() to kvm_find_cpuid_entry{,index}() now that cpuid_entry2_find() operates on the vCPU state, i.e. now that there is no need to use cpuid_entry2_find() directly in order to pass in non-vCPU state. To help prevent unwanted usage of cpuid_entry2_find(), #undef KVM

[PATCH v3 37/57] KVM: x86: Advertise TSC_DEADLINE_TIMER in KVM_GET_SUPPORTED_CPUID

Unconditionally advertise TSC_DEADLINE_TIMER via KVM_GET_SUPPORTED_CPUID, as KVM always emulates deadline mode, *if* the VM has an in-kernel local APIC. The odds of a VMM emulating the local APIC in userspace, not emulating the TSC deadline timer, _and_ reflecting KVM_GET_SUPPORTED_CPUID back into

[PATCH v3 35/57] KVM: x86: Move kvm_find_cpuid_entry{,_index}() up near cpuid_entry2_find()

Move kvm_find_cpuid_entry{,_index}() "up" in cpuid.c so that they are colocated with cpuid_entry2_find(), e.g. to make it easier to see the effective guts of the helpers without having to bounce around cpuid.c. No functional change intended. Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christ

[PATCH v3 38/57] KVM: x86: Advertise HYPERVISOR in KVM_GET_SUPPORTED_CPUID

Unconditionally advertise "support" for the HYPERVISOR feature in CPUID, as the flag simply communicates to the guest that's it's running under a hypervisor. Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson --- arch/x86/kvm/cpuid.c | 3 ++- 1 file changed, 2 insertions(+), 1 delet

[PATCH v3 39/57] KVM: x86: Rename "governed features" helpers to use "guest_cpu_cap"

As the first step toward replacing KVM's so-called "governed features" framework with a more comprehensive, less poorly named implementation, replace the "kvm_governed_feature" function prefix with "guest_cpu_cap" and rename guest_can_use() to guest_cpu_cap_has(). The "guest_cpu_cap" naming scheme

[PATCH v3 41/57] KVM: x86: Initialize guest cpu_caps based on guest CPUID

Initialize a vCPU's capabilities based on the guest CPUID provided by userspace instead of simply zeroing the entire array. This is the first step toward using cpu_caps to query *all* CPUID-based guest capabilities, i.e. will allow converting all usage of guest_cpuid_has() to guest_cpu_cap_has().

[PATCH v3 40/57] KVM: x86: Replace guts of "governed" features with comprehensive cpu_caps

Replace the internals of the governed features framework with a more comprehensive "guest CPU capabilities" implementation, i.e. with a guest version of kvm_cpu_caps. Keep the skeleton of governed features around for now as vmx_adjust_sec_exec_control() relies on detecting governed features to do

[PATCH v3 42/57] KVM: x86: Extract code for generating per-entry emulated CPUID information

Extract the meat of __do_cpuid_func_emulated() into a separate helper, cpuid_func_emulated(), so that cpuid_func_emulated() can be used with a single CPUID entry. This will allow marking emulated features as fully supported in the guest cpu_caps without needing to hardcode the set of emulated feat

[PATCH v3 43/57] KVM: x86: Treat MONTIOR/MWAIT as a "partially emulated" feature

Enumerate MWAIT in cpuid_func_emulated(), but only if the caller wants to include "partially emulated" features, i.e. features that KVM kinda sorta emulates, but with major caveats. This will allow initializing the guest cpu_caps based on the set of features that KVM virtualizes and/or emulates, w

[PATCH v3 44/57] KVM: x86: Initialize guest cpu_caps based on KVM support

Constrain all guest cpu_caps based on KVM support instead of constraining only the few features that KVM _currently_ needs to verify are actually supported by KVM. The intent of cpu_caps is to track what the guest is actually capable of using, not the raw, unfiltered CPUID values that the guest se

[PATCH v3 45/57] KVM: x86: Avoid double CPUID lookup when updating MWAIT at runtime

Move the handling of X86_FEATURE_MWAIT during CPUID runtime updates to utilize the lookup done for other CPUID.0x1 features. No functional change intended. Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson --- arch/x86/kvm/cpuid.c | 13 + 1 file changed, 5 insertions(+

[PATCH v3 50/57] KVM: x86: Replace (almost) all guest CPUID feature queries with cpu_caps

Switch all queries (except XSAVES) of guest features from guest CPUID to guest capabilities, i.e. replace all calls to guest_cpuid_has() with calls to guest_cpu_cap_has(). Keep guest_cpuid_has() around for XSAVES, but subsume its helper guest_cpuid_get_register() and add a compile-time assertion t

[PATCH v3 51/57] KVM: x86: Drop superfluous host XSAVE check when adjusting guest XSAVES caps

Drop the manual boot_cpu_has() checks on XSAVE when adjusting the guest's XSAVES capabilities now that guest cpu_caps incorporates KVM's support. The guest's cpu_caps are initialized from kvm_cpu_caps, which are in turn initialized from boot_cpu_data, i.e. checking guest_cpu_cap_has() also checks h

[PATCH v3 49/57] KVM: x86: Shuffle code to prepare for dropping guest_cpuid_has()

Move the implementations of guest_has_{spec_ctrl,pred_cmd}_msr() down below guest_cpu_cap_has() so that their use of guest_cpuid_has() can be replaced with calls to guest_cpu_cap_has(). No functional change intended. Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson --- arch/x86/k

[PATCH v3 48/57] KVM: x86: Update guest cpu_caps at runtime for dynamic CPUID-based features

When updating guest CPUID entries to emulate runtime behavior, e.g. when the guest enables a CR4-based feature that is tied to a CPUID flag, also update the vCPU's cpu_caps accordingly. This will allow replacing all usage of guest_cpuid_has() with guest_cpu_cap_has(). Note, this relies on kvm_set

[PATCH v3 47/57] KVM: x86: Update OS{XSAVE,PKE} bits in guest CPUID irrespective of host support

When making runtime CPUID updates, change OSXSAVE and OSPKE even if their respective base features (XSAVE, PKU) are not supported by the host. KVM already incorporates host support in the vCPU's effective reserved CR4 bits. I.e. OSXSAVE and OSPKE can be set if and only if the host supports them.

[PATCH v3 46/57] KVM: x86: Drop unnecessary check that cpuid_entry2_find() returns right leaf

Drop an unnecessary check that kvm_find_cpuid_entry_index(), i.e. cpuid_entry2_find(), returns the correct leaf when getting CPUID.0x7.0x0 to update X86_FEATURE_OSPKE. cpuid_entry2_find() never returns an entry for the wrong function. And not that it matters, but cpuid_entry2_find() will always r

[PATCH v3 57/57] KVM: x86: Use only local variables (no bitmask) to init kvm_cpu_caps

Refactor the kvm_cpu_cap_init() macro magic to collect supported features in a local variable instead of passing them to the macro as a "mask". As pointed out by Maxim, relying on macros to "return" a value and set local variables is surprising, as the bitwise-OR logic suggests the macros are pure

[PATCH v3 55/57] KVM: x86: Explicitly track feature flags that require vendor enabling

Add another CPUID feature macro, VENDOR_F(), and use it to track features that KVM supports, but that need additional vendor support and so are conditionally enabled in vendor code. Currently, VENDOR_F() is mostly just documentation, but tracking all KVM-supported features will allow for asserting

[PATCH v3 53/57] KVM: x86: Pull CPUID capabilities from boot_cpu_data only as needed

Don't memcpy() all of boot_cpu_data.x86_capability, and instead explicitly fill each kvm_cpu_cap_init leaf during kvm_cpu_cap_init(). While clever, copying all kernel capabilities risks over-reporting KVM capabilities, e.g. if KVM added support in __do_cpuid_func(), but neglected to init the suppo

[PATCH v3 54/57] KVM: x86: Rename "SF" macro to "SCATTERED_F"

Now that each feature flag is on its own line, i.e. brevity isn't a major concern, drop the "SF" acronym and use the (almost) full name, SCATTERED_F. No functional change intended. Signed-off-by: Sean Christopherson --- arch/x86/kvm/cpuid.c | 12 ++-- 1 file changed, 6 insertions(+), 6

Re: [GIT PULL] Modules changes for v6.13-rc1

On Thu, Nov 28, 2024 at 11:56:44AM +0900, Masahiro Yamada wrote: > On Thu, Nov 28, 2024 at 11:42 AM Luis Chamberlain wrote: > > > > Now with Masahiro's cleanups, in my testing we don't need the FORCE anymore. > > > > > > From 83497e0e83d81950df54d82461b1dae629842147 Mon Sep 17 00:00:00 2001 > > Fr

Re: [GIT PULL] Modules changes for v6.13-rc1

Hi Linus and Luis, On Thu, Nov 28, 2024 at 8:57 AM Linus Torvalds wrote: > > On Wed, 27 Nov 2024 at 15:26, Luis Chamberlain wrote: > > > > On Wed, Nov 27, 2024 at 02:35:36PM -0800, Luis Chamberlain wrote: > > > Sorry about that, I'm on it. > > > > OK here is a fix, goes double build tested and

Re: [PATCH] virtio_net: drain unconsumed tx completions if any before dql_reset

On Thu, Nov 28, 2024 at 10:57:01AM +0800, Jason Wang wrote: > On Wed, Nov 27, 2024 at 12:08 PM Koichiro Den > wrote: > > > > On Wed, Nov 27, 2024 at 11:24:15AM +0800, Jason Wang wrote: > > > On Tue, Nov 26, 2024 at 12:44 PM Koichiro Den > > > wrote: > > > > > > > > On Tue, Nov 26, 2024 at 11:50:1

  1   2   >