- Prevent confusing messages from being printed if the PRMT table
is not present or there are no PRM modules (Aubrey Li).
- Fix the handling of suspend-to-idle entry and exit in the case
when the Microsoft UUID is used with the Low-Power S0 Idle _DSM
interface (Mario Limonciello).
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmEgAlESHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRxqtUP/17Ij8yvXGV2INb2S744FyLgvjk0FdgZ
xcRhqEdYdPVqaZ75myTo+pSl7uArusO5HrKG4nRx7ATWovpb6+xK9H+ZmxyZfDkx
Y1tb4kM3ms17JOFs8KGFtcQA9V+qJZPK7JRXGaVw9rh1B7fAf/8T/gKH2/9Yh2hn
F0QrZUo0ihvcRBGeznoT/LxHy4hs5NEaEKf4AUcwdkOFPl/T+HspUESXY9SgVK4p
jKdumPe9ws/GukiLsRFNMPCj73W4Ejab7E4JqCWfvFyAkDih0Ud9MPNpdCb2nxhl
XJb1TGkXuW7PR2K+lgJBWTgRUmf4K/AbH3v7dR0B33PQfQru+BP9X6x8dDBn47Uu
Etpoxoh8is+AQ66x3yc8P4dWH297/zF9XkYGr5S9y73QJFs9+UKDTpZNIEKrRllF
sHCAueZmj45f3vjJeoNBzbOg6cu/TPNqPizGUphQU4t6SMEbCMU8sAlq12lLCM+4
doQDq7nS4x2hYpDSsR8m+61TNdzclsa64L2AZGUuwzFht2EqHt+aKpzv3cVS3rES
M8Q1w3ViTmOEKp4SlfRNaFh0NUDT7/kH+i7UzwFMqvny/CVbW0LX50RCois+bYMQ
3wUUCOMwGgmdIe+/LkiFV+deKcETR2bsFPbIdmvzjqCU5AhQRS8ihwKeZk5ozjnM
Ae70TtKyM1R7
=GBtH
-----END PGP SIGNATURE-----
Merge tag 'acpi-5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fixes from Rafael Wysocki:
"These fix two mistakes in new code.
Specifics:
- Prevent confusing messages from being printed if the PRMT table is
not present or there are no PRM modules (Aubrey Li).
- Fix the handling of suspend-to-idle entry and exit in the case when
the Microsoft UUID is used with the Low-Power S0 Idle _DSM
interface (Mario Limonciello)"
* tag 'acpi-5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: PM: s2idle: Invert Microsoft UUID entry and exit
ACPI: PRM: Deal with table not present or no module found
- Fix unuseful WARN() in the OPP core and prevent a noisy warning
from being printed by OPP _put functions (Dmitry Osipenko).
- Fix error path when allocation failed in the arm_scmi cpufreq
driver (Lukasz Luba).
- Blacklist Qualcomm sc8180x and Qualcomm sm8150 in
cpufreq-dt-platdev (Bjorn Andersson, Thara Gopinath).
- Forbid cpufreq for 1.2 GHz variant in the armada-37xx cpufreq
driver (Marek Behún).
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmEgAqQSHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRxbG8P/ioTb6ZpoE+/Nx1QqnhJ0eOBoOE0ynjc
2llwknuFox4ZyOau6d+WZgxzs4Ka3XEwhhO4Ki0qjMMeag+jmyqZAPAAVB4ED1g1
dHyWOsNA2Bf/ONs1iK60WBlxU9FnWeQoqqEyywUjL0XEnsYqSnaEHR1gzv5zy2Cn
pJiE4db6jFj1OXsOZGCJSptZsoGoCaPyiv2MvpVTjyuCz5fV3gWJnvEE5LslvNMP
l3TMGSKtnbTNCOCpkuOVPObXaNGzWXp3RNoGRyp8r7VbQfbVu1Oqhv3EbaeGVW1X
vmWr+qC/zbYEE/JTvdb8riBO50UuYK570yo39IQIRTqyjK/DfB/E7FTq+amQsA8y
GtwEiBCZGhcJWn7B5xLjREyPDnuPLiG5x71MTP/gdMmx5DRkp/3eB6c6e11xapLH
fLeuV4cEt38SbAyuznj5cr0lkzu/E7tqQyt9Ol2r9hyoW5N3G1ubAh7nx+HOEw3Z
2/29knqM9XXbYw/DTv+9EL5KfOPPd9+NRC4ZycNhbgDov7y88HfJdfMVZRwsaTHK
iF+WGotJz4HI/DH7qTID4IlLIth9sTCCV5SXaUURp9/OCwbMYVZCLPM2vB/aN4ir
dt6ojtrhz6Rvn4KohbSUmwkKetW8789qLblOsv+5+mYO56eBeH7RP0qd/V1OyZw3
UNkOrQz0Nm6F
=lQtW
-----END PGP SIGNATURE-----
Merge tag 'pm-5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"These fix some issues in the ARM cpufreq drivers and in the operating
performance points (OPP) framework.
Specifics:
- Fix useless WARN() in the OPP core and prevent a noisy warning
from being printed by OPP _put functions (Dmitry Osipenko).
- Fix error path when allocation failed in the arm_scmi cpufreq
driver (Lukasz Luba).
- Blacklist Qualcomm sc8180x and Qualcomm sm8150 in
cpufreq-dt-platdev (Bjorn Andersson, Thara Gopinath).
- Forbid cpufreq for 1.2 GHz variant in the armada-37xx cpufreq
driver (Marek Behún)"
* tag 'pm-5.14-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
opp: Drop empty-table checks from _put functions
cpufreq: armada-37xx: forbid cpufreq for 1.2 GHz variant
cpufreq: blocklist Qualcomm sm8150 in cpufreq-dt-platdev
cpufreq: arm_scmi: Fix error path when allocation failed
opp: remove WARN when no valid OPPs remain
cpufreq: blacklist Qualcomm sc8180x in cpufreq-dt-platdev
The kernel test robot found the following bug when running xfs/355 to
scrub a bmap btree:
XFS: Assertion failed: !sa->pag, file: fs/xfs/scrub/common.c, line: 412
------------[ cut here ]------------
kernel BUG at fs/xfs/xfs_message.c:110!
invalid opcode: 0000 [#1] SMP PTI
CPU: 2 PID: 1415 Comm: xfs_scrub Not tainted 5.14.0-rc4-00021-g48c6615cc557 #1
Hardware name: Hewlett-Packard p6-1451cx/2ADA, BIOS 8.15 02/05/2013
RIP: 0010:assfail+0x23/0x28 [xfs]
RSP: 0018:ffffc9000aacb890 EFLAGS: 00010202
RAX: 0000000000000000 RBX: ffffc9000aacbcc8 RCX: 0000000000000000
RDX: 00000000ffffffc0 RSI: 000000000000000a RDI: ffffffffc09e7dcd
RBP: ffffc9000aacbc80 R08: ffff8881fdf17d50 R09: 0000000000000000
R10: 000000000000000a R11: f000000000000000 R12: 0000000000000000
R13: ffff88820c7ed000 R14: 0000000000000001 R15: ffffc9000aacb980
FS: 00007f185b955700(0000) GS:ffff8881fdf00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7f6ef43000 CR3: 000000020de38002 CR4: 00000000001706e0
Call Trace:
xchk_ag_read_headers+0xda/0x100 [xfs]
xchk_ag_init+0x15/0x40 [xfs]
xchk_btree_check_block_owner+0x76/0x180 [xfs]
xchk_btree_get_block+0xd0/0x140 [xfs]
xchk_btree+0x32e/0x440 [xfs]
xchk_bmap_btree+0xd4/0x140 [xfs]
xchk_bmap+0x1eb/0x3c0 [xfs]
xfs_scrub_metadata+0x227/0x4c0 [xfs]
xfs_ioc_scrub_metadata+0x50/0xc0 [xfs]
xfs_file_ioctl+0x90c/0xc40 [xfs]
__x64_sys_ioctl+0x83/0xc0
do_syscall_64+0x3b/0xc0
The unusual handling of errors while initializing struct xchk_ag is the
root cause here. Since the beginning of xfs_scrub, the goal of
xchk_ag_read_headers has been to read all three AG header buffers and
attach them both to the xchk_ag structure and the scrub transaction.
Corruption errors on any of the three headers doesn't necessarily
trigger an immediate return to userspace, because xfs_scrub can also
tell us to /fix/ the problem.
In other words, it's possible for the xchk_ag init functions to return
an error code and a partially filled out structure so that scrub can use
however much information it managed to pull. Before 5.15, it was
sufficient to cancel (or commit) the scrub transaction on the way out of
the scrub code to release the buffers.
Ccommit 48c6615cc5 added a reference to the perag structure to struct
xchk_ag. Since perag structures are not attached to transactions like
buffers are, this adds the requirement that the perag ref be released
explicitly. The scrub teardown function xchk_teardown was amended to do
this for the xchk_ag embedded in struct xfs_scrub.
Unfortunately, I forgot that certain parts of the scrub code probe
multiple AGs and therefore handle the initialization and cleanup on
their own. Specifically, the bmbt scrubber will initialize it long
enough to cross-reference AG metadata for btree blocks and for the
extent mappings in the bmbt.
If one of the AG headers is corrupt, the init function returns with a
live perag structure reference and some of the AG header buffers. If an
error occurs, the cross referencing will be noted as XCORRUPTion and
skipped, but the main scrub process will move on to the next record.
It is now necessary to release the perag reference before we try to
analyze something from a different AG, or else we'll trip over the
assertion noted above.
Fixes: 48c6615cc5 ("xfs: grab active perag ref when reading AG headers")
Reported-by: kernel test robot <oliver.sang@intel.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Chandan Babu R <chandanrlinux@gmail.com>
Several users of the VPD API use a fixed-size buffer and read the VPD into
it for further usage. This requires special handling for the case that the
buffer isn't big enough to hold the full VPD data. Also the buffer is
often allocated on the stack, which isn't too nice.
Add pci_vpd_alloc() to dynamically allocate buffer of the correct size and
read VPD into it.
Link: https://lore.kernel.org/r/955ff598-0021-8446-f856-0c2c077635d7@gmail.com
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
When the 5-level page table is enabled on host OS, the nested page table
for guest VMs must use 5-level as well. Update get_npt_level() function
to reflect this requirement. In the meanwhile, remove the code that
prevents kvm-amd driver from being loaded when 5-level page table is
detected.
Signed-off-by: Wei Huang <wei.huang2@amd.com>
Message-Id: <20210818165549.3771014-4-wei.huang2@amd.com>
[Tweak condition as suggested by Sean. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When the 5-level page table CPU flag is set in the host, but the guest
has CR4.LA57=0 (including the case of a 32-bit guest), the top level of
the shadow NPT page tables will be fixed, consisting of one pointer to
a lower-level table and 511 non-present entries. Extend the existing
code that creates the fixed PML4 or PDP table, to provide a fixed PML5
table if needed.
This is not needed on EPT because the number of layers in the tables
is specified in the EPTP instead of depending on the host CR4.
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wei Huang <wei.huang2@amd.com>
Message-Id: <20210818165549.3771014-3-wei.huang2@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The ima documentation for measuring DM targets (dm-ima.rst) is
missing the attribute information for the targets - 'cache', 'integrity',
'multipath', and 'snapshot'. It is also missing the grammar for
various DM events and targets, which can help the attestation servers
to determine what data to expect for a given DM device. Further,
the documentation needs to be updated to incorporate code changes
made to DM ima events and targets as part of this patch series. For
instance, prefixing the event names with "dm_", adding the DM version to
events, prefixing the table hashes in the ima log with the
hash algorithm etc. There are warnings reported by 'make htmldocs' on
dm-ima.rst, which need to be fixed. And lastly, the expected behavior
needs to be documented when the configuration CONFIG_IMA_DISABLE_HTABLE
is disabled.
Update the documentation to add examples for 'cache', 'integrity',
'multipath', and 'snapshot' targets. Add the grammar for
various DM events and targets in Backus Naur form,
so that the attestation servers can interpret and act on the ima
measurements for DM target. Fix htmldocs warnings in dm-ima.rst. Update
the documentation to be consistent with the code changes that are part of
this patch series.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Certain DM targets ('integrity', 'multipath', 'verity') need to update the
way their attributes are recorded in the ima log, so that the attestation
servers can interpret the data correctly and decide if the devices
meet the attestation requirements. For instance, the "mode=%c" attribute
in the 'integrity' target is measured twice, the 'verity' target is
missing the attribute "root_hash_sig_key_desc=%s", and the 'multipath'
target needs to index the attributes properly.
Update 'integrity' target to remove the duplicate measurement of
the attribute "mode=%c". Add "root_hash_sig_key_desc=%s" attribute
for the 'verity' target. Index various attributes in 'multipath'
target. Also, add "nr_priority_groups=%u" attribute to 'multipath'
target to record the number of priority groups.
Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
Suggested-by: Thore Sommer <public@thson.de>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
The end-users of DM devices/targets may remove and re-create the same
device multiple times. IMA does not measure such duplicate events if the
configuration CONFIG_IMA_DISABLE_HTABLE is set to 'n'.
To avoid confusion, the end-users need some indication on the client
if that configuration option is disabled.
Add a one-time warning during dm_init() if CONFIG_IMA_DISABLE_HTABLE
is set to 'n', to notify the end-users that duplicate events will not
be measured in the ima log. Also cleanup some whitespace in dm_init().
Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
AMD future CPUs will require a 5-level NPT if host CR4.LA57 is set.
To prevent kvm_mmu_get_tdp_level() from incorrectly changing NPT level
on behalf of CPUs, add a new parameter in kvm_configure_mmu() to force
a fixed TDP level.
Signed-off-by: Wei Huang <wei.huang2@amd.com>
Message-Id: <20210818165549.3771014-2-wei.huang2@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This change started as a way to make kvm_mmu_hugepage_adjust a bit simpler,
but it does fix two bugs as well.
One bug is in zapping collapsible PTEs. If a large page size is
disallowed but not all of them, kvm_mmu_max_mapping_level will return the
host mapping level and the small PTEs will be zapped up to that level.
However, if e.g. 1GB are prohibited, we can still zap 4KB mapping and
preserve the 2MB ones. This can happen for example when NX huge pages
are in use.
The second would happen when userspace backs guest memory
with a 1gb hugepage but only assign a subset of the page to
the guest. 1gb pages would be disallowed by the memslot, but
not 2mb. kvm_mmu_max_mapping_level() would fall through to the
host_pfn_mapping_level() logic, see the 1gb hugepage, and map the whole
thing into the guest.
Fixes: 2f57b7051f ("KVM: x86/mmu: Persist gfn_lpage_is_disallowed() to max_level")
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Modify debug_regs test to create a pending interrupt
and see that it is blocked when single stepping is done
with KVM_GUESTDBG_BLOCKIRQ
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20210811122927.900604-7-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
KVM_GUESTDBG_BLOCKIRQ will allow KVM to block all interrupts
while running.
This change is mostly intended for more robust single stepping
of the guest and it has the following benefits when enabled:
* Resuming from a breakpoint is much more reliable.
When resuming execution from a breakpoint, with interrupts enabled,
more often than not, KVM would inject an interrupt and make the CPU
jump immediately to the interrupt handler and eventually return to
the breakpoint, to trigger it again.
From the user point of view it looks like the CPU never executed a
single instruction and in some cases that can even prevent forward
progress, for example, when the breakpoint is placed by an automated
script (e.g lx-symbols), which does something in response to the
breakpoint and then continues the guest automatically.
If the script execution takes enough time for another interrupt to
arrive, the guest will be stuck on the same breakpoint RIP forever.
* Normal single stepping is much more predictable, since it won't
land the debugger into an interrupt handler.
* RFLAGS.TF has less chance to be leaked to the guest:
We set that flag behind the guest's back to do single stepping
but if single step lands us into an interrupt/exception handler
it will be leaked to the guest in the form of being pushed
to the stack.
This doesn't completely eliminate this problem as exceptions
can still happen, but at least this reduces the chances
of this happening.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20210811122927.900604-6-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Split the check for having a vmexit handler to svm_check_exit_valid,
and make svm_handle_invalid_exit only handle a vmexit that is
already not valid.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20210811122927.900604-2-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Drop @shared from tdp_mmu_link_page() and hardcode it to work for
mmu_lock being held for read. The helper has exactly one caller and
in all likelihood will only ever have exactly one caller. Even if KVM
adds a path to install translations without an initiating page fault,
odds are very, very good that the path will just be a wrapper to the
"page fault" handler (both SNP and TDX RFCs propose patches to do
exactly that).
No functional change intended.
Cc: Ben Gardon <bgardon@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20210810224554.2978735-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Existing KVM code tracks the number of large pages regardless of their
sizes. Therefore, when large page of 1GB (or larger) is adopted, the
information becomes less useful because lpages counts a mix of 1G and 2M
pages.
So remove the lpages since it is easy for user space to aggregate the info.
Instead, provide a comprehensive page stats of all sizes from 4K to 512G.
Suggested-by: Ben Gardon <bgardon@google.com>
Reviewed-by: David Matlack <dmatlack@google.com>
Reviewed-by: Ben Gardon <bgardon@google.com>
Signed-off-by: Mingwei Zhang <mizhang@google.com>
Cc: Jing Zhang <jingzhangos@google.com>
Cc: David Matlack <dmatlack@google.com>
Cc: Sean Christopherson <seanjc@google.com>
Message-Id: <20210803044607.599629-4-mizhang@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Factor in whether or not the old/new SPTEs are shadow-present when
adjusting the large page stats in the TDP MMU. A modified MMIO SPTE can
toggle the page size bit, as bit 7 is used to store the MMIO generation,
i.e. is_large_pte() can get a false positive when called on a MMIO SPTE.
Ditto for nuking SPTEs with REMOVED_SPTE, which sets bit 7 in its magic
value.
Opportunistically move the logic below the check to verify at least one
of the old/new SPTEs is shadow present.
Use is/was_leaf even though is/was_present would suffice. The code
generation is roughly equivalent since all flags need to be computed
prior to the code in question, and using the *_leaf flags will minimize
the diff in a future enhancement to account all pages, i.e. will change
the check to "is_leaf != was_leaf".
Reviewed-by: David Matlack <dmatlack@google.com>
Reviewed-by: Ben Gardon <bgardon@google.com>
Fixes: 1699f65c8b ("kvm/x86: Fix 'lpages' kvm stat for TDM MMU")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Mingwei Zhang <mizhang@google.com>
Message-Id: <20210803044607.599629-3-mizhang@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Drop an unnecessary is_shadow_present_pte() check when updating the rmaps
after installing a non-MMIO SPTE. set_spte() is used only to create
shadow-present SPTEs, e.g. MMIO SPTEs are handled early on, mmu_set_spte()
runs with mmu_lock held for write, i.e. the SPTE can't be zapped between
writing the SPTE and updating the rmaps.
Opportunistically combine the "new SPTE" logic for large pages and rmaps.
No functional change intended.
Suggested-by: Ben Gardon <bgardon@google.com>
Reviewed-by: David Matlack <dmatlack@google.com>
Reviewed-by: Ben Gardon <bgardon@google.com>
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Mingwei Zhang <mizhang@google.com>
Message-Id: <20210803044607.599629-2-mizhang@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add three log histogram stats to record the distribution of time spent
on successful polling, failed polling and VCPU wait.
halt_poll_success_hist: Distribution of spent time for a successful poll.
halt_poll_fail_hist: Distribution of spent time for a failed poll.
halt_wait_hist: Distribution of time a VCPU has spent on waiting.
Signed-off-by: Jing Zhang <jingzhangos@google.com>
Message-Id: <20210802165633.1866976-6-jingzhangos@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add simple stats halt_wait_ns to record the time a VCPU has spent on
waiting for all architectures (not just powerpc).
Signed-off-by: Jing Zhang <jingzhangos@google.com>
Message-Id: <20210802165633.1866976-5-jingzhangos@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The bucket_size field should be non-zero for linear histogram stats and
should be zero for other stats types.
Reviewed-by: David Matlack <dmatlack@google.com>
Signed-off-by: Jing Zhang <jingzhangos@google.com>
Message-Id: <20210802165633.1866976-4-jingzhangos@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add documentations for linear and logarithmic histogram statistics.
Signed-off-by: Jing Zhang <jingzhangos@google.com>
Message-Id: <20210802165633.1866976-3-jingzhangos@google.com>
[Small changes to the phrasing. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add new types of KVM stats, linear and logarithmic histogram.
Histogram are very useful for observing the value distribution
of time or size related stats.
Signed-off-by: Jing Zhang <jingzhangos@google.com>
Message-Id: <20210802165633.1866976-2-jingzhangos@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
APIC base relocation is not supported anyway and won't work
correctly so just drop the code that handles it and keep AVIC
MMIO bar at the default APIC base.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20210810205251.424103-17-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently it is possible to have the following scenario:
1. AVIC is disabled by svm_refresh_apicv_exec_ctrl
2. svm_vcpu_blocking calls avic_vcpu_put which does nothing
3. svm_vcpu_unblocking enables the AVIC (due to KVM_REQ_APICV_UPDATE)
and then calls avic_vcpu_load
4. warning is triggered in avic_vcpu_load since
AVIC_PHYSICAL_ID_ENTRY_IS_RUNNING_MASK was never cleared
While it is possible to just remove the warning, it seems to be more robust
to fully disable/enable AVIC in svm_refresh_apicv_exec_ctrl by calling the
avic_vcpu_load/avic_vcpu_put
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20210810205251.424103-16-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Since AVIC can be inhibited and uninhibited rapidly it is possible that
we have nothing to do by the time the svm_refresh_apicv_exec_ctrl
is called.
Detect and avoid this, which will be useful when we will start calling
avic_vcpu_load/avic_vcpu_put when the avic inhibition state changes.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20210810205251.424103-14-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Now that kvm_request_apicv_update doesn't need to drop the kvm->srcu lock,
we can call kvm_request_apicv_update directly.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20210810205251.424103-13-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
APICV_INHIBIT_REASON_HYPERV is currently unconditionally forced upon
SynIC activation as SynIC's AutoEOI is incompatible with APICv/AVIC. It is,
however, possible to track whether the feature was actually used by the
guest and only inhibit APICv/AVIC when needed.
TLFS suggests a dedicated 'HV_DEPRECATING_AEOI_RECOMMENDED' flag to let
Windows know that AutoEOI feature should be avoided. While it's up to
KVM userspace to set the flag, KVM can help a bit by exposing global
APICv/AVIC enablement.
Maxim:
- always set HV_DEPRECATING_AEOI_RECOMMENDED in kvm_get_hv_cpuid,
since this feature can be used regardless of AVIC
Paolo:
- use arch.apicv_update_lock to protect the hv->synic_auto_eoi_used
instead of atomic ops
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20210810205251.424103-12-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
It is never a good idea to enter a guest on a vCPU when the
AVIC inhibition state doesn't match the enablement of
the AVIC on the vCPU.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20210810205251.424103-11-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently on SVM, the kvm_request_apicv_update toggles the APICv
memslot without doing any synchronization.
If there is a mismatch between that memslot state and the AVIC state,
on one of the vCPUs, an APIC mmio access can be lost:
For example:
VCPU0: enable the APIC_ACCESS_PAGE_PRIVATE_MEMSLOT
VCPU1: access an APIC mmio register.
Since AVIC is still disabled on VCPU1, the access will not be intercepted
by it, and neither will it cause MMIO fault, but rather it will just be
read/written from/to the dummy page mapped into the
APIC_ACCESS_PAGE_PRIVATE_MEMSLOT.
Fix that by adding a lock guarding the AVIC state changes, and carefully
order the operations of kvm_request_apicv_update to avoid this race:
1. Take the lock
2. Send KVM_REQ_APICV_UPDATE
3. Update the apic inhibit reason
4. Release the lock
This ensures that at (2) all vCPUs are kicked out of the guest mode,
but don't yet see the new avic state.
Then only after (4) all other vCPUs can update their AVIC state and resume.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20210810205251.424103-10-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Thanks to the former patches, it is now possible to keep the APICv
memslot always enabled, and it will be invisible to the guest
when it is inhibited
This code is based on a suggestion from Sean Christopherson:
https://lkml.org/lkml/2021/7/19/2970
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20210810205251.424103-9-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
on AMD, APIC virtualization needs to dynamicaly inhibit the AVIC in a
response to some events, and this is problematic and not efficient to do by
enabling/disabling the memslot that covers APIC's mmio range.
Plus due to SRCU locking, it makes it more complex to
request AVIC inhibition.
Instead, the APIC memslot will be always enabled, but be invisible
to the guest, such as the MMU code will not install a SPTE for it,
when it is inhibited and instead jump straight to emulating the access.
When inhibiting the AVIC, this SPTE will be zapped.
This code is based on a suggestion from Sean Christopherson:
https://lkml.org/lkml/2021/7/19/2970
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20210810205251.424103-8-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This will allow it to return RET_PF_EMULATE for APIC mmio
emulation.
This code is based on a patch from Sean Christopherson:
https://lkml.org/lkml/2021/7/19/2970
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20210810205251.424103-7-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
try_async_pf is a wrong name for this function, since this code
is used when asynchronous page fault is not enabled as well.
This code is based on a patch from Sean Christopherson:
https://lkml.org/lkml/2021/7/19/2970
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20210810205251.424103-6-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This together with previous patch, ensures that
kvm_zap_gfn_range doesn't race with page fault
running on another vcpu, and will make this page fault code
retry instead.
This is based on a patch suggested by Sean Christopherson:
https://lkml.org/lkml/2021/7/22/1025
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20210810205251.424103-5-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This comment makes it clear that the range of gfns that this
function receives is non inclusive.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20210810205251.424103-4-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
kvm_flush_remote_tlbs_with_address expects (start gfn, number of pages),
and not (start gfn, end gfn)
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20210810205251.424103-3-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This together with the next patch will fix a future race between
kvm_zap_gfn_range and the page fault handler, which will happen
when AVIC memslot is going to be only partially disabled.
The performance impact is minimal since kvm_zap_gfn_range is only
called by users, update_mtrr() and kvm_post_set_cr0().
Both only use it if the guest has non-coherent DMA, in order to
honor the guest's UC memtype.
MTRR and CD setup only happens at boot, and generally in an area
where the page tables should be small (for CD) or should not
include the affected GFNs at all (for MTRRs).
This is based on a patch suggested by Sean Christopherson:
https://lkml.org/lkml/2021/7/22/1025
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20210810205251.424103-2-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Use this file to dump rmap statistic information. The statistic is done by
calculating the rmap count and the result is log-2-based.
An example output of this looks like (idle 6GB guest, right after boot linux):
Rmap_Count: 0 1 2-3 4-7 8-15 16-31 32-63 64-127 128-255 256-511 512-1023
Level=4K: 3086676 53045 12330 1272 502 121 76 2 0 0 0
Level=2M: 5947 231 0 0 0 0 0 0 0 0 0
Level=1G: 32 0 0 0 0 0 0 0 0 0 0
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20210730220455.26054-5-peterx@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Introduce kvm_mmu_slot_lpages() to calculcate lpage_info and rmap array size.
The other __kvm_mmu_slot_lpages() can take an extra parameter of npages rather
than fetching from the memslot pointer. Start to use the latter one in
kvm_alloc_memslot_metadata().
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20210730220455.26054-4-peterx@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The event names for the DM events recorded in the ima log do not contain
any information to indicate the events are part of the DM devices/targets.
Prefix the event names for DM events with "dm_" to indicate that they
are part of device-mapper.
Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
Suggested-by: Thore Sommer <public@thson.de>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
core:
- fix drm_wait_vblank uapi copying bug
ttm:
- fix debugfs init when debugfs is off
amdgpu:
- vega10 SMU workload fix
- DCN VM fix
- DCN 3.01 watermark fix
amdkfd:
- SVM fix
nouveau:
- ampere display fixes
- remove MM misfeature to fix a longstanding race condition
i915:
- tweaked display workaround for all PCHs
- eDP MSO pipe sanity for ADL-P fix
- remove unused symbol export
mediatek:
- AAL output size setting
- Delete component in remove function
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmEfPsgACgkQDHTzWXnE
hr5BEg//QPG86+IybghlzsLRtzyC/YnE12gkkREmq67gNqY8rVUdC8jR7nq2OJWa
S1M6WR0wLR9mfw+zLr6HXnaP5+KqGe0JqnJVIyMx50LSL8qJzttO5wHzp+G2tI7C
+lPozccei+VirWj351Qall+TmV1s2I1h/QnW/CyGEa/uQ8iZXr7+1fad3st8194c
Lzb+qFvwykEa4jeo8oD2OHiCHCGkTkI1cnSt9g7/BMCzRr5KuNaFAd5hvSUaQyfD
5FX+0/sPiGRzIbLDHU/xTVvdvDcSW0w8+x93EcPkaGLfQd7FNzOCoEOwdYvBqcSL
p49rIEwfAltyHKKvqajD05DUAe+XS+LGhN99ykW1zoO+s9qPchzNrAaGImrZlbw+
JAruyxW2NhxBBXGlx0AgyCBdbWjydosfIToj/GXf7uXZRkxxtNQlFj56i+PT0hx3
Xadc7BBNZvHYY5JCi9oEDttrsQUexRy9XWTfN9o1I7oN4Uuksn7CtRXSHG/UfYa2
90z6rVTmAaS8h/3Ir5FMBY/O8aQbKHK27Rui9vgSmRNMwxKUun2+UjKJLC8DFZFu
zx4mc5p+ByC3GmLb9G4FOj1DI5ZeNIHrX/JD6Lf78ooje+vW5mme1iMGQp+jlb6C
FAtpNteDMeqY/b5piJDoJ0qWxqm0YqL2K5S1mDauPPthAu73uS8=
=7B9v
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2021-08-20-3' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"Regularly scheduled fixes. The ttm one solves a problem of GPU drivers
failing to load if debugfs is off in Kconfig, otherwise the i915 and
mediatek, and amdgpu fixes all fairly normal.
Nouveau has a couple of display fixes, but it has a fix for a
longstanding race condition in it's memory manager code, and the fix
mostly removes some code that wasn't working properly and has no
userspace users. This fix makes the diffstat kinda larger but in a
good (negative line-count) way.
core:
- fix drm_wait_vblank uapi copying bug
ttm:
- fix debugfs init when debugfs is off
amdgpu:
- vega10 SMU workload fix
- DCN VM fix
- DCN 3.01 watermark fix
amdkfd:
- SVM fix
nouveau:
- ampere display fixes
- remove MM misfeature to fix a longstanding race condition
i915:
- tweaked display workaround for all PCHs
- eDP MSO pipe sanity for ADL-P fix
- remove unused symbol export
mediatek:
- AAL output size setting
- Delete component in remove function"
* tag 'drm-fixes-2021-08-20-3' of git://anongit.freedesktop.org/drm/drm:
drm/amd/display: Use DCN30 watermark calc for DCN301
drm/i915/dp: remove superfluous EXPORT_SYMBOL()
drm/i915/edp: fix eDP MSO pipe sanity checks for ADL-P
drm/i915: Tweaked Wa_14010685332 for all PCHs
drm/nouveau: rip out nvkm_client.super
drm/nouveau: block a bunch of classes from userspace
drm/nouveau/fifo/nv50-: rip out dma channels
drm/nouveau/kms/nv50: workaround EFI GOP window channel format differences
drm/nouveau/disp: power down unused DP links during init
drm/nouveau: recognise GA107
drm: Copy drm_wait_vblank to user before returning
drm/amd/display: Ensure DCN save after VM setup
drm/amdkfd: fix random KFDSVMRangeTest.SetGetAttributesTest test failure
drm/amd/pm: change the workload type for some cards
Revert "drm/amd/pm: fix workload mismatch on vega10"
drm: ttm: Don't bail from ttm_global_init if debugfs_create_dir fails
drm/mediatek: Add component_del in OVL and COLOR remove function
drm/mediatek: Add AAL output size configuration
The DM events present in the ima log contain various attributes in the
key=value format. The attributes' names/values may change in future,
and new attributes may also get added. The attestation server needs
some versioning to determine which attributes are supported and are
expected in the ima log.
Add version information to the DM events present in the ima log to
help attestation servers to correctly process the attributes across
different versions.
Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
The active/inactive table hashes measured in the ima log do not contain
the information about hash algorithm. This information is useful for the
attestation servers to recreate the hashes and compare them with the ones
present in the ima log to verify the table contents.
Prefix the table hashes in various DM events in ima log with the hash
algorithm used to compute those hashes.
Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
- dw_mmc: Fix hang on data CRC error
- mmci: Fix voltage switch procedure for the stm32 variant
- sdhci-iproc: Fix some clock issues for BCM2711
- sdhci-msm: Fixup software timeout value
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAmEfq70XHHVsZi5oYW5z
c29uQGxpbmFyby5vcmcACgkQ/iaEJXNYjCmnpw/5AcGohl2QCQsPaFootvgXGqlG
cBPw9Ag5sK8GCD+hdEJ9Yj+LPCiLESJsk6+4SeMFFwWfBgDv9z6j8dSfZtAYp06/
lRyT2eI4zIOXWVxTkr7KUdacjF9EySbrTug6m7VN4yNb1dxL6Xsl/frTqk8FmqW7
T7HI67fJM795reqw0PEiWeSL+2191aOLFUp17spYsCdMrsc77cgrrH1AaWyVFFr6
P7C/ZvHHsF3MI3yNPfz4QLwHnGffCCLxTQdeJ+EmMsKGIoQTga1aAl4t3nwb+ZIR
b8zRIReGdXXq5bw6BwDzKaTMyyvLN0B85EtfwyVsDsw76evp8QEC6ZMIKvQCB260
jj4fqCpfgkCBLnD2LnkL2vZZ3MQAJ1v3RRlWwChm/FBYVmsVrKjK71ZlMiEt2H9m
KZJnQ8t+OoooFjAEb6u+1q8inPtsLjFY9433FWYg1pfiD9STHQ28FTUD7JtYPhvy
alxQCqykQChWpMHfhiUzWM2LJSxt/ts5yrvdlrRuIb6uwBrT2841e/2SG+0YCraN
Hg3tOs2z/O4EdDYMXH3blJFSi4emzGeDnuLyRFOxI/akvnpucEdpnFvmaSsG5rk5
x6FLljAFiKUM755I14dLsLq1rzqs/E956Fl1g3BNmEsBfZFed6PKLBNRG6shIbAY
N6L/4D7VaAeZvek2/Og=
=Y+uG
-----END PGP SIGNATURE-----
Merge tag 'mmc-v5.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Pull MMC host fixes from Ulf Hansson:
- dw_mmc: Fix hang on data CRC error
- mmci: Fix voltage switch procedure for the stm32 variant
- sdhci-iproc: Fix some clock issues for BCM2711
- sdhci-msm: Fixup software timeout value
* tag 'mmc-v5.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
mmc: sdhci-iproc: Set SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN on BCM2711
mmc: sdhci-iproc: Cap min clock frequency on BCM2711
mmc: sdhci-msm: Update the software timeout value for sdhc
mmc: mmci: stm32: Check when the voltage switch procedure should be done
mmc: dw_mmc: Fix hang on data CRC error
This is a quick follow up for 5.14: a fix for a very recently
introduced regression on ASoC Intel Atom driver, and another
trivial HD-audio quirk for HP laptops.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmEfYhcOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE+stw//fgVv0pqPXLBRB/6mZY4nzyP+4+s2PCAFpnKk
iW0c5ATJC9tf77S8iVWWUVExEURIOoqBcoNupRNkf5hmI/snzSMN/NvBvJy0oeJA
qK3e0a3KSIdOofSEFl1Xvek5iOYY1Zjt9F+SAnZuAF2pGZ6uxbPg2t4vwHIBEu7f
CBxixyvjoGvJpro4BdDqIpKJ0QOkI9yiCN9SlUxmcg3bCzfLI2eklrGrR0NUWkkk
BIUQElKIJ6/b7/J1/LhW8bK2XiNj6fls4NoblTW93dzoSiqu40fZVJeum+9T3V9s
pNHegqKO8T4nznr4zzam/8u6+6CVnZj295g8FWX3Vn9SMefeD/MfZV/1sRldBjyX
tXMEVt0b/0+L90AyMnoH0xedqpT+ETcz8PYuWb3d14dStHI+op+IvzaCNd8WQ/8I
2zbNXwEvUZ4wVWxHJQqNEn3k3CRdlZg82WPdCR074gsUMKPgMCM5J9WQ2fNxtwZM
u1nalKcUAoBjbPl8kFxYb/mcWgXIP+zvB8MvRDVIl88k+scW6GsrIrBaOfYwvX3U
omlAdRpHyjkjxfbxA/bKrgdIhU31/ZcfuF59+Ert1mNb9WsEMMTePBXvrxmjZL9L
UoNFD811bVzkZBMO3sMjSTLe3bEYnpzei2FYkLGFiGFq5xRm+k/FFeyVaENpwO6E
b5Y4mmg=
=QNEK
-----END PGP SIGNATURE-----
Merge tag 'sound-5.14-rc7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull more sound fixes from Takashi Iwai:
"This is a quick follow up for 5.14: a fix for a very recently
introduced regression on ASoC Intel Atom driver, and another trivial
HD-audio quirk for HP laptops"
* tag 'sound-5.14-rc7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ASoC: intel: atom: Fix breakage for PCM buffer address setup
ALSA: hda/realtek: Limit mic boost on HP ProBook 445 G8
