The life cycle of a vGPU, which is represented by a vfio_device, has been
managed by the VFIO core logic. Remove the vgpu->released, which was used
for a sanity check on the removal path of the vGPU instance. The sanity
check has already been covered in the VFIO core logic.
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Cc: intel-gvt-dev@lists.freedesktop.org
Suggested-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20221104145652.1570-1-zhi.a.wang@intel.com
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
struct gvt_firmware_header has a crc32 member in which all members that
come after the that field are used to calculate it. The previous
implementation added the value '4' (crc32's u32 size) to calculate the
crc32_start offset which came across as a bit cryptic until you take a
deeper look at the struct.
This patch changes crc32_start offset to the 'version' member which is
the first member of the struct gvt_firmware_header after crc32.
It's worth mentioning that doing a build before/after this patch results
in no binary output differences.
Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20221030033628.GA279284@mail.google.com
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Some functions seem to have been renamed without updating the kernel-doc
markup causing warnings. Also, struct intel_vgpu_dmabuf_obj is not
properly documented, but has a kerneld-doc markup.
Fix those warnings:
drivers/gpu/drm/i915/gvt/aperture_gm.c:308: warning: expecting prototype for inte_gvt_free_vgpu_resource(). Prototype was for intel_vgpu_free_resource() instead
drivers/gpu/drm/i915/gvt/aperture_gm.c:344: warning: expecting prototype for intel_alloc_vgpu_resource(). Prototype was for intel_vgpu_alloc_resource() instead
drivers/gpu/drm/i915/gvt/cfg_space.c:257: warning: expecting prototype for intel_vgpu_emulate_cfg_read(). Prototype was for intel_vgpu_emulate_cfg_write() instead
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'vgpu' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'info' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'dmabuf_id' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'kref' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'initref' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or member 'list' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/handlers.c:3066: warning: expecting prototype for intel_t_default_mmio_write(). Prototype was for intel_vgpu_default_mmio_write() instead
drivers/gpu/drm/i915/gvt/mmio_context.c:560: warning: expecting prototype for intel_gvt_switch_render_mmio(). Prototype was for intel_gvt_switch_mmio() instead
drivers/gpu/drm/i915/gvt/page_track.c:131: warning: expecting prototype for intel_vgpu_enable_page_track(). Prototype was for intel_vgpu_disable_page_track() instead
drivers/gpu/drm/i915/gvt/vgpu.c:215: warning: expecting prototype for intel_gvt_active_vgpu(). Prototype was for intel_gvt_activate_vgpu() instead
drivers/gpu/drm/i915/gvt/vgpu.c:230: warning: expecting prototype for intel_gvt_deactive_vgpu(). Prototype was for intel_gvt_deactivate_vgpu() instead
drivers/gpu/drm/i915/gvt/vgpu.c:358: warning: expecting prototype for intel_gvt_destroy_vgpu(). Prototype was for intel_gvt_destroy_idle_vgpu() instead
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/375c0c0ca2ef414f25e14f274457f77373a9268d.1657699522.git.mchehab@kernel.org
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
There is a spelling mistake in a gvt_vgpu_err error message. Fix it.
Fixes: 695fbc08d8 ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err")
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20220315202449.2952845-1-colin.i.king@gmail.com
Reviewed-by: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Remove unused parameters and cleanup dead code.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Clean that up a bit, no functional change.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The basic problem here is that it's not allowed to page fault while
holding the reservation lock.
So it can happen that multiple processes try to validate an userptr
at the same time.
Work around that by putting the HMM range object into the mutex
protected bo list for now.
v2: make sure range is set to NULL in case of an error
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
CC: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Since switching to HMM we always need that because we no longer grab
references to the pages.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
CC: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Now that we've fixed the issue with using the incorrect topology manager,
we're actually grabbing the topology manager's lock - and consequently
deadlocking. Luckily for us though, there's actually nothing in AMD's DSC
state computation code that really should need this lock. The one exception
is the mutex_lock() in dm_dp_mst_is_port_support_mode(), however we grab no
locks beneath &mgr->lock there so that should be fine to leave be.
Gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 8c20a1ed9b ("drm/amd/display: MST DSC compute fair share")
Cc: <stable@vger.kernel.org> # v5.6+
Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This bug hurt me. Basically, it appears that we've been grabbing the
entirely wrong mutex in the MST DSC computation code for amdgpu! While
we've been grabbing:
amdgpu_dm_connector->mst_mgr
That's zero-initialized memory, because the only connectors we'll ever
actually be doing DSC computations for are MST ports. Which have mst_mgr
zero-initialized, and instead have the correct topology mgr pointer located
at:
amdgpu_dm_connector->mst_port->mgr;
I'm a bit impressed that until now, this code has managed not to crash
anyone's systems! It does seem to cause a warning in LOCKDEP though:
[ 66.637670] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
This was causing the problems that appeared to have been introduced by:
commit 4d07b0bc40 ("drm/display/dp_mst: Move all payload info into the atomic state")
This wasn't actually where they came from though. Presumably, before the
only thing we were doing with the topology mgr pointer was attempting to
grab mst_mgr->lock. Since the above commit however, we grab much more
information from mst_mgr including the atomic MST state and respective
modesetting locks.
This patch also implies that up until now, it's quite likely we could be
susceptible to race conditions when going through the MST topology state
for DSC computations since we technically will not have grabbed any lock
when going through it.
So, let's fix this by adjusting all the respective code paths to look at
the right pointer and skip things that aren't actual MST connectors from a
topology.
Gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 8c20a1ed9b ("drm/amd/display: MST DSC compute fair share")
Cc: <stable@vger.kernel.org> # v5.6+
Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Looks like that we're accidentally dropping a pretty important return code
here. For some reason, we just return -EINVAL if we fail to get the MST
topology state. This is wrong: error codes are important and should never
be squashed without being handled, which here seems to have the potential
to cause a deadlock.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Fixes: 8ec046716c ("drm/dp_mst: Add helper to trigger modeset on affected DSC MST CRTCs")
Cc: <stable@vger.kernel.org> # v5.6+
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It appears that amdgpu makes the mistake of completely ignoring the return
values from the DP MST helpers, and instead just returns a simple
true/false. In this case, it seems to have come back to bite us because as
a result of simply returning false from
compute_mst_dsc_configs_for_state(), amdgpu had no way of telling when a
deadlock happened from these helpers. This could definitely result in some
kernel splats.
V2:
* Address Wayne's comments (fix another bunch of spots where we weren't
passing down return codes)
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 8c20a1ed9b ("drm/amd/display: MST DSC compute fair share")
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: <stable@vger.kernel.org> # v5.6+
Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Assert on non-OK response from SMU is unnecessary.
It was replaced with respective log message on other asics
in the past with commit:
"drm/amd/display: Removing assert statements for Linux"
[How]
Remove assert and add dbg logging as on other DCNs.
Signed-off-by: Roman Li <roman.li@amd.com>
Reviewed-by: Saaem Rizvi <SyedSaaem.Rizvi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Move the new callback outside of the guard.
Fixes: dc55b106ad ("drm/amd/display: Disable phantom OTG after enable for plane disable")
CC: Alvin Lee <Alvin.Lee2@amd.com>
CC: Alan Liu <HaoPing.Liu@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
As of now only device names are printed out over __xfs_printk().
The device names are not persistent across reboots which in case
of searching for origin of corruption brings another task to properly
identify the devices. This patch add XFS UUID upon every mount/umount
event which will make the identification much easier.
Signed-off-by: Lukas Herbolt <lukas@herbolt.com>
[sandeen: rebase onto current upstream kernel]
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
When lazysbcount is enabled, fsstress and loop mount/unmount test report
the following problems:
XFS (loop0): SB summary counter sanity check failed
XFS (loop0): Metadata corruption detected at xfs_sb_write_verify+0x13b/0x460,
xfs_sb block 0x0
XFS (loop0): Unmount and run xfs_repair
XFS (loop0): First 128 bytes of corrupted metadata buffer:
00000000: 58 46 53 42 00 00 10 00 00 00 00 00 00 28 00 00 XFSB.........(..
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020: 69 fb 7c cd 5f dc 44 af 85 74 e0 cc d4 e3 34 5a i.|._.D..t....4Z
00000030: 00 00 00 00 00 20 00 06 00 00 00 00 00 00 00 80 ..... ..........
00000040: 00 00 00 00 00 00 00 81 00 00 00 00 00 00 00 82 ................
00000050: 00 00 00 01 00 0a 00 00 00 00 00 04 00 00 00 00 ................
00000060: 00 00 0a 00 b4 b5 02 00 02 00 00 08 00 00 00 00 ................
00000070: 00 00 00 00 00 00 00 00 0c 09 09 03 14 00 00 19 ................
XFS (loop0): Corruption of in-memory data (0x8) detected at _xfs_buf_ioapply
+0xe1e/0x10e0 (fs/xfs/xfs_buf.c:1580). Shutting down filesystem.
XFS (loop0): Please unmount the filesystem and rectify the problem(s)
XFS (loop0): log mount/recovery failed: error -117
XFS (loop0): log mount failed
This corruption will shutdown the file system and the file system will
no longer be mountable. The following script can reproduce the problem,
but it may take a long time.
#!/bin/bash
device=/dev/sda
testdir=/mnt/test
round=0
function fail()
{
echo "$*"
exit 1
}
mkdir -p $testdir
while [ $round -lt 10000 ]
do
echo "******* round $round ********"
mkfs.xfs -f $device
mount $device $testdir || fail "mount failed!"
fsstress -d $testdir -l 0 -n 10000 -p 4 >/dev/null &
sleep 4
killall -w fsstress
umount $testdir
xfs_repair -e $device > /dev/null
if [ $? -eq 2 ];then
echo "ERR CODE 2: Dirty log exception during repair."
exit 1
fi
round=$(($round+1))
done
With lazysbcount is enabled, There is no additional lock protection for
reading m_ifree and m_icount in xfs_log_sb(), if other cpu modifies the
m_ifree, this will make the m_ifree greater than m_icount. For example,
consider the following sequence and ifreedelta is postive:
CPU0 CPU1
xfs_log_sb xfs_trans_unreserve_and_mod_sb
---------- ------------------------------
percpu_counter_sum(&mp->m_icount)
percpu_counter_add_batch(&mp->m_icount,
idelta, XFS_ICOUNT_BATCH)
percpu_counter_add(&mp->m_ifree, ifreedelta);
percpu_counter_sum(&mp->m_ifree)
After this, incorrect inode count (sb_ifree > sb_icount) will be writen to
the log. In the subsequent writing of sb, incorrect inode count (sb_ifree >
sb_icount) will fail to pass the boundary check in xfs_validate_sb_write()
that cause the file system shutdown.
When lazysbcount is enabled, we don't need to guarantee that Lazy sb
counters are completely correct, but we do need to guarantee that sb_ifree
<= sb_icount. On the other hand, the constraint that m_ifree <= m_icount
must be satisfied any time that there /cannot/ be other threads allocating
or freeing inode chunks. If the constraint is violated under these
circumstances, sb_i{count,free} (the ondisk superblock inode counters)
maybe incorrect and need to be marked sick at unmount, the count will
be rebuilt on the next mount.
Fixes: 8756a5af18 ("libxfs: add more bounds checking to sb sanity checks")
Signed-off-by: Long Li <leo.lilong@huawei.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Clean up resources if resetting the dotdot entry doesn't succeed.
Observed through code inspection.
Fixes: 5838d0356b ("xfs: reset child dir '..' entry when unlinking child")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com>
Running the online fsck QA fuzz tests, I noticed that we were
consistently missing fuzzed records in the inode cores of the realtime
freespace files and the quota files. This patch adds the ability to
check inode cores in xchk_metadata_inode_forks.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmN1fwwACgkQ+H93GTRK
tOuqAw/+JLnoGvDkkWfLHqFqroINQp29ZEuk2Zgcn9E1Lk+7xfZimqRNdlJI47J3
Dz9ob5gO/GZfZoPtfmxQegJggaHnjRb1LLQGphb5EDhB7ezo23JQt8lM7A4iPVx9
KHhb/+7IIJLNt07p2RpyTxPjdmxk1s0vYpnjchnSrxUR1Lqzq5LU1CLVEbwfHyRI
PJX3OCG57fbk5jOFo/KgkKXP/cf6//PP/pGT56ytzveBMZt77D3dWtRSEiQGlUc2
QFlR77CR4KuLhkRjr69B1X2RVEopj4/sRItSMpFB/EoPpfDsYrGw27Pm8fgdVyTo
VLUzCS8NlhkVikoEO8EBawLidRT1QlgluqNVUUKx/+NSA5DsroymkEj8+BzL7mJO
vsHEGZw/IeTn9ATqapQtjHc6ZnbZFHCaf0b+eaJhuoMjyOI+guleYjIHQcaLTK73
pivmCoj6VE6V1IZNZAnFEAohNPCxpfzu85Sg7mVUcrL24QReOIuy21m207Tj3q94
6ytXENkOdJJ3ZJq1MoIIhAvOJPmzJvGEEpv+auSdu+OfeYK/kXbtcCPFIwtcI0p5
1fnKKq/y9mZyr+37Ifx74DBAiCeO+GHikkYOIP70Lkw0YQ3AVnU7PQBy1xmJCzYG
AlAebztXXED+uJbhvNICOrxuSXzVynKpN6Br3VYT7qfgCGjS8L8=
=mvcx
-----END PGP SIGNATURE-----
Merge tag 'scrub-check-metadata-inode-records-6.2_2022-11-16' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.2-mergeA
xfs: scrub inode core when checking metadata files
Running the online fsck QA fuzz tests, I noticed that we were
consistently missing fuzzed records in the inode cores of the realtime
freespace files and the quota files. This patch adds the ability to
check inode cores in xchk_metadata_inode_forks.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
* tag 'scrub-check-metadata-inode-records-6.2_2022-11-16' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux:
xfs: check inode core when scrubbing metadata files
xfs: don't warn about files that are exactly s_maxbytes long
This series strengthens the file extent mapping scrubber in various
ways, such as confirming that there are enough bmap records to match up
with the rmap records for this file, checking delalloc reservations,
checking for no unwritten extents in metadata files, invalid CoW fork
formats, and weird things like shared CoW fork extents.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmN1fwsACgkQ+H93GTRK
tOtCsQ/7BZO0D8QyAJH3DBBNoK90EpM19YjB7LbD6ExHLMTCzR2bitrR0W0NPey1
kS74/owG6cmCvqIem5bLIQB8hhnQAnhswEVEW4HmhmKq0QBZFdGhJK+C/pgpL072
SgKzNzU86CB0+StVJTGRd5jgWWzLSajEPbRXoNS1nat63F6aqx44zI8Gehn5qjhD
S2ldj7FUIWK0qV2dfb0szP8zzD8H7GvE1msXjEuFRWdVqFMHbKaTC+sfoYIE0cMK
WllJ8RVXX4BqgWmeJSuidy/ryWhOXGsW0/UDXxe8yLlw/eIYSP2hm/J/KPBf+Zd8
2ntJnnK19ggjM0TusmkXjupjrXR8zMP3gh3lcYJ3a37HM991aIZ18ffMNXj7y4+n
1T2CerePVWaUQ0K2L/tErBAeY9dolM0pux1dwEdvU9LdYTD1SgAmnOJ3HhVYiXbG
vIZ/e7F6VrccUKXHxmokj21PZldxJ5GpJgPMIsVOuMilh8Thnc+C/rD8XALytHww
fydvqTSKuIgKw7VJNnXhLgZK2JQBr6+jHhsC9nUay394tooNdoyZDwLeYJcM0Tnt
8d8/PalGOdGJHZH212LqeyQ44xIjAxjx4CuE4XLkuTEz7FPDqiXpzFpK+wYa3Ocn
c75ngS5WAqslbna2U/UtV/vol2np2gA+QYhELpCl5r2EPsrPyes=
=ZRqi
-----END PGP SIGNATURE-----
Merge tag 'scrub-bmap-enhancements-6.2_2022-11-16' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.2-mergeA
xfs: strengthen file mapping scrub
This series strengthens the file extent mapping scrubber in various
ways, such as confirming that there are enough bmap records to match up
with the rmap records for this file, checking delalloc reservations,
checking for no unwritten extents in metadata files, invalid CoW fork
formats, and weird things like shared CoW fork extents.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
* tag 'scrub-bmap-enhancements-6.2_2022-11-16' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux:
xfs: teach scrub to flag non-extents format cow forks
xfs: check that CoW fork extents are not shared
xfs: check quota files for unwritten extents
xfs: block map scrub should handle incore delalloc reservations
xfs: teach scrub to check for adjacent bmaps when rmap larger than bmap
xfs: fix perag loop in xchk_bmap_check_rmaps
This series makes two changes to the fs summary counter scrubber: first,
we should mark the scrub incomplete when we can't read the AG headers.
Second, it fixes a functionality gap where we don't actually check the
free rt extent count.
v23.2: fix pointless inline
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmN1fwsACgkQ+H93GTRK
tOv8EA/8CYkmhVy79KQSEJ33/b9qf62gNOsUlIDr3800FxWEyz/j1luK2yWF/4+4
cU8V/GcR8G9WLETHbCAFGsA1DTRsoDyIBZ51m3jmMsRaeF2sGCMaLR9kAs+4Mzbr
fhRIAlnQGL0BHkQW/lC/3GR1d9w5mBYgScvY5rzqo01AjEMs3nWr2IgHzmTlRKdz
26gPQcaHLhEkadv013XJYTNpcP3iBb1QeQ5E1zmBO32cvzyY9Jcza7dpDx6KvAvN
99SjAuxt2ZD8ecf+eiaCvWwdqduoZRGI2J+7YpHnk1GS18AjC4mepzkUQ9lNra3j
9BzekTpxTK0jZ3wQTkIiYRTpGAPkfXRJBDkvy7WEu6S434mneL/KqJBX5UZiDduy
7486xkBh1agncOHfU6XypC/k2b3oa1svMGvVDcUzYzH9EStaAm+CY37/DjEVcwgM
i2TAVignUJjqjx9nS7PmM76hrFBMksHhRU/crBK1yxF2JrKkdoeluFa5MabJVj9M
sicMwrra4wfuueAMRHZlfAhDW9a+ud6mSnnP7ndlBQXowc8PgrYvovfwZpL6C7q+
gr8/DV+1+zvLFQedyUDcn7rnzxMZ5yUQO7ehBzqt/0QoMT5DLBD/5i63nTh+Ms1G
pgIDx0BDL4GhDBmwGP84xwuEBcwNKmD9s8cMgUB/D58/vZAyXTc=
=IZks
-----END PGP SIGNATURE-----
Merge tag 'scrub-fscounters-enhancements-6.2_2022-11-16' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.2-mergeA
xfs: enhance fs summary counter scrubber
This series makes two changes to the fs summary counter scrubber: first,
we should mark the scrub incomplete when we can't read the AG headers.
Second, it fixes a functionality gap where we don't actually check the
free rt extent count.
v23.2: fix pointless inline
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
* tag 'scrub-fscounters-enhancements-6.2_2022-11-16' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux:
xfs: online checking of the free rt extent count
xfs: skip fscounters comparisons when the scan is incomplete
This short series makes some small changes to the way we handle the
realtime metadata inodes. First, we now make sure that the bitmap and
summary file forks are always loaded at mount time so that every
scrubber won't have to call xfs_iread_extents. This won't be easy if
we're, say, cross-referencing realtime space allocations. The second
change makes the ILOCK annotations more consistent with the rest of XFS.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmN1fwoACgkQ+H93GTRK
tOsLwg/+K27LJjHR9FF/Wpj4A4yupWPj91LYtB10Vd2TVjd6xUoCPxuYBUDctjGG
jb40eEg3hE8qFjaOavA8TgY5Od4M0EcdZKnZm9rLIB2w/WYjq00ZW13dnk6n5GXr
9y3OzSEHOyzimbvjddOLv/jyaeUJV8m6uKls653Ou2wRWXmT4oVmYeJGPSv8ZKjL
NLmE4zC9o7Qi8UfDOX6r9mrwQgLZLF3qHTGAQrGI0GG+TPjp4PI/SeN4WB27H0Ue
VklFPlMh2/Nmo4mfKoNupRLw2G0ZgMM4akkhdG2b0rHO9DC27/swycYUzKUV/pMP
L5rlzXE7a2eeia2OF1/HECBJ4meUvJI1qlxm8wMZTPCu92J49swE4o5CUhNhyo3e
31LLf9kiFaJnmWxxDOrDUGP8tK461MfRX3moGpLPNMPjks0QiLE61fbW6FsH7Dlu
CwPwVXSgr6JSfYjHpMMDwmYGI9li2KUmuDXXvjEvx0yAU/D2+R8HyTZiVmJiXHXK
kseQUTYv8BEloQAFmejf5pPqe3IRQ0CTGuS89k4uoGE2bXaQGwFsvof8ASePM02L
ITI4x1aYRRTMnfrj4VFIlK2oAvet9opV7mODW1repSM3OpYXSW7b/uHg5CY/u4eC
JrOr222viO1C26p+cCqHaiWn/WxIHy6/Dl3Ju5R55dINNjpFCfs=
=Nuyw
-----END PGP SIGNATURE-----
Merge tag 'scrub-fix-rtmeta-ilocking-6.2_2022-11-16' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.2-mergeA
xfs: improve rt metadata use for scrub
This short series makes some small changes to the way we handle the
realtime metadata inodes. First, we now make sure that the bitmap and
summary file forks are always loaded at mount time so that every
scrubber won't have to call xfs_iread_extents. This won't be easy if
we're, say, cross-referencing realtime space allocations. The second
change makes the ILOCK annotations more consistent with the rest of XFS.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
* tag 'scrub-fix-rtmeta-ilocking-6.2_2022-11-16' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux:
xfs: make rtbitmap ILOCKing consistent when scanning the rt bitmap file
xfs: load rtbitmap and rtsummary extent mapping btrees at mount time
Here we fix a couple of problems with the errno values that we return to
userspace.
v23.2: fix vague wording of comment
v23.3: fix the commit message to discuss what's really going on in this
patch
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmN1fwkACgkQ+H93GTRK
tOtqHxAAiKPUgjMDRHIBmVTYEmHo0QuxnBcPAMUmwlX5sAjtVZFHnIZ1ChfdR/K2
eDzfFLbNnxyW8HdkI6O7aP7XD/HVFkKRmzWdVkzA463scaFnCVrLl8NDecmZRtVS
TTHCCnDmzdZYM2uDayPJyZAHKZZejp6j33+N6bFBwtNYij9yBEFkHyIP+xZRmPVr
RU1rzzmXhrZqB3ci/8bfOQbkaGzotEAu6R+pFddvMQ55hSwtY7OZ1IctlqHkRlks
H86jGbcd8KNsi0SKo0RN+IuS2LtZNesI0Sm95LUOn1HnlEtmeHrJZYqC5WrKB3cn
gUKJlzgEaDU7eCjMhd6TolqE6zNi/3xMaqjxS/Utoe3wSwSkQvGFVIuJiew7OXFQ
BIDXxpOV/4C+vyi83CDcD147iLXJqz3RFECMD1HXDClYDXEEu9Qk3shJaDQQsOS/
Ddn7UhuF80JcFsf0ZjpwuLwJdsAvDGruD/652V/3D3zkOHiqL9ejMI/InHuU/Fnu
zGeignES4yVcJZMeOL8+crYM1EHGYjZRwe8qOEv4ufND+LnwAu71vyGmtfVqdki5
Qo3n0x1K0dk0Um+YPJrZSfeuSNdpGfBexR1rvWOdAuPJfrizaqHmWg/7fs3ZNSqG
Zfye7jpUcFNt8cxLmwHcNPxI5ll7Kev/4eaWzsz23v4ZTP39m0A=
=UIK1
-----END PGP SIGNATURE-----
Merge tag 'scrub-fix-return-value-6.2_2022-11-16' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.2-mergeA
xfs: fix incorrect return values in online fsck
Here we fix a couple of problems with the errno values that we return to
userspace.
v23.2: fix vague wording of comment
v23.3: fix the commit message to discuss what's really going on in this
patch
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
* tag 'scrub-fix-return-value-6.2_2022-11-16' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux:
xfs: don't return -EFSCORRUPTED from repair when resources cannot be grabbed
xfs: don't retry repairs harder when EAGAIN is returned
xfs: fix return code when fatal signal encountered during dquot scrub
xfs: return EINTR when a fatal signal terminates scrub
This series standardizes the GFP_ flags that we use for memory
allocation in online scrub, and convert the callers away from the old
kmem_alloc code that was ported from Irix.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmN1fwgACgkQ+H93GTRK
tOsdEA/+PrgIsICn+TE+ypTNnpCTmO+EbJ5uhmK8c/P7JcWuyuM2kHSfo5Q0y6Pv
lOF+MXUgPBXbWB1UIxSDJX4U9yaGGZE41tNpILN3Q1hd9WhMAtHLgvDwv+UdGV2J
/yILLD03pytSmE/SQunO4/0MgA2v1vIhyyoLXF63BbLq3HZ5I1JsezHE4gaZ8vdU
CnVUYGs9/qvDPDzYqVyoCBRI9yWx9GebanwceVP+kuwzmVN+ITSsrn5MjUVWbzro
lxTz7xBGkXF0Q4l5RHpDzVGrUj2Zs1GnoWrd8VAGfZqQi/lHsMXZp8yctzlviPm0
AJkfPWuWLBmmaUdDlgNOHLOojSTYj4n4P/t5OccylnJs8cPuP5UsJdMip1GQfHOO
mxjctZxrdIv5AdJBmG4M8hF7B4dHGIY66B+imfD0xueiB5b9pMHJOYuVn33iPQZe
Ga70dTEQfqD/MNUy9cAYevRHxcy8kU6B96TgYmNNHdhvJCweQozQ3xyEQB1LHReh
pJRnlARauMZJyZmj9GMB2VMnFi8Ghb/JP8qPEHWdm+WkqOS0oRI88kUVRfm2IHIG
n5/BfVWSFAV6xrMrlUnlM9qMpGjNYpg5wyDBO7VRK3VjNoFoYqpGTfQ4LrAX6mUh
KzEtcm7i4Ur7MenC+P9lx0ZOl4CpD73cIs17AJyLozbjZnaalZg=
=foY/
-----END PGP SIGNATURE-----
Merge tag 'scrub-cleanup-malloc-6.2_2022-11-16' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.2-mergeA
xfs: clean up memory allocations in online fsck
This series standardizes the GFP_ flags that we use for memory
allocation in online scrub, and convert the callers away from the old
kmem_alloc code that was ported from Irix.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
* tag 'scrub-cleanup-malloc-6.2_2022-11-16' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux:
xfs: pivot online scrub away from kmem.[ch]
xfs: initialize the check_owner object fully
xfs: standardize GFP flags usage in online scrub
While reading through the online fsck code, I noticed that the setup
code for AG metadata scrubs will attach the AGI, the AGF, and the AGFL
buffers to the transaction. It isn't necessary to hold the AGFL buffer,
since any code that wants to do anything with the AGFL will need to hold
the AGF to know which parts of the AGFL are active. Therefore, we only
need to hold the AGFL when scrubbing the AGFL itself.
The second bug fixed by this patchset is one that I observed while
testing online repair. When a buffer is held across a transaction roll,
its buffer log item will be detached if the bli was clean before the
roll. If we are holding the AG headers to maintain a lock on an AG, we
then need to set the buffer type on the new bli to avoid confusing the
logging code later.
There's also a bug fix for uninitialized memory in the directory scanner
that didn't fit anywhere else.
Ths patchset finishes off by teaching the AGFL repair function to look
for and discard crosslinked blocks instead of putting them back on the
AGFL.
v23.2: Log the buffers before rolling the transaction to keep the moving
forward in the log and avoid the bli falling off.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmN1fwAACgkQ+H93GTRK
tOvOrA//duBabr1KtTxEnTALDiQCsXJwSV/G6wQ8OO7KGpi+cBxGMiTStp28oDPw
rzg2qBFpt/Yr3vpyNPZz3qjaYY3/EHlz+SZrSlMnHXXXXl2diDXCGZYWpl2EQtEX
MljQ7HW9ux4CDzT1vfkAnwuYPlTzX166ISFtvJrJKoK4qDEn2nCdZn9fmrDVXlTU
sMtvYzgDofo83JoZTDS8rbVEXP883E9nUwdDgKxrGUef4QIeArEcIhCnb8xSF/6q
kQWDn9axn80JMhF5UKd0uwow9q11LvvGnYB+uK5RV6Kv7fja016spVN2xOT1B09E
vf+IBauz3/UaGuOIhq+9/rW3Pg4I3eeQUI3K+Px9OIW65Ascc+Zm2E2JWVaz/ZJd
jtt2iRmhYvSCwCRrP1nmMhtK6PCN8luY1hNvHfIul6MVYm6fi0pDfmevFEUEsoG/
UIRdzO5HcBZac4B9GbLGIL+tySimIwqND3yXuDlXKygHMXnkXstDcKDUb52MzFy2
mPoKNPGs4vmwymooPJHvD9ANPYQ9PWkrU0DLj2Sn1cs72yHYuKyQM4VPqTJRO7WZ
bcGkqMMYpmqjf+fePE3u7DQnNLYUMXIFR4caCyxjESc52ZPQbigBOfqliYveUgtQ
y7hXCxL7nVvUOGYs/S6JgMFfpwMeoAOrqBaZYLlPf1N95TNVgBc=
=1yOQ
-----END PGP SIGNATURE-----
Merge tag 'scrub-fix-ag-header-handling-6.2_2022-11-16' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-6.2-mergeA
xfs: fix handling of AG[IF] header buffers during scrub
While reading through the online fsck code, I noticed that the setup
code for AG metadata scrubs will attach the AGI, the AGF, and the AGFL
buffers to the transaction. It isn't necessary to hold the AGFL buffer,
since any code that wants to do anything with the AGFL will need to hold
the AGF to know which parts of the AGFL are active. Therefore, we only
need to hold the AGFL when scrubbing the AGFL itself.
The second bug fixed by this patchset is one that I observed while
testing online repair. When a buffer is held across a transaction roll,
its buffer log item will be detached if the bli was clean before the
roll. If we are holding the AG headers to maintain a lock on an AG, we
then need to set the buffer type on the new bli to avoid confusing the
logging code later.
There's also a bug fix for uninitialized memory in the directory scanner
that didn't fit anywhere else.
Ths patchset finishes off by teaching the AGFL repair function to look
for and discard crosslinked blocks instead of putting them back on the
AGFL.
v23.2: Log the buffers before rolling the transaction to keep the moving
forward in the log and avoid the bli falling off.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
* tag 'scrub-fix-ag-header-handling-6.2_2022-11-16' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux:
xfs: make AGFL repair function avoid crosslinked blocks
xfs: log the AGI/AGF buffers when rolling transactions during an AG repair
xfs: don't track the AGFL buffer in the scrub AG context
xfs: fully initialize xfs_da_args in xchk_directory_blocks
Add the node for SA2UL for supporting hardware crypto algorithms,
including SHA1, SHA256, SHA512, AES, 3DES and AEAD suites.
Add rng node for hardware random number generator.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
Acked-by: Matt Ranostay <mranostay@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20221031200633.26997-1-j-choudhary@ti.com
The x1-clk used by trng submodule comes directly from the system clock
after a fixed divider. It is always running and has a fixed frequency
that cannot be changed, making it uncontrollable. Hence this property
should be dropped from the rng node.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20221107110607.59216-4-j-choudhary@ti.com
The x1-clk used by trng submodule comes directly from the system clock
after a fixed divider. It is always running and has a fixed frequency
that cannot be changed, making it uncontrollable. Hence this property
should be dropped from the rng node.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20221107110607.59216-3-j-choudhary@ti.com
The x1-clk used by trng submodule comes directly from the system clock
after a fixed divider. It is always running and has a fixed frequency
that cannot be changed, making it uncontrollable. Hence this property
should be dropped from the rng node.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20221107110607.59216-2-j-choudhary@ti.com
If root-node has no reg property, the unit-address should not
be appended at the end of node-name. 'sound' node has no 'reg'
property, so remove the unit-address.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Jai Luthra <j-luthra@ti.com>
Link: https://lore.kernel.org/r/20220928122509.143342-1-j-choudhary@ti.com
Move the declaration of 'struct trace_array' out of #ifdef
CONFIG_TRACING block, to fix the following warning when CONFIG_TRACING
is not set:
>> include/linux/trace.h:63:45: warning: 'struct trace_array' declared
inside parameter list will not be visible outside of this definition or
declaration
Link: https://lkml.kernel.org/r/20221107160556.2139463-1-shraash@google.com
Fixes: 1a77dd1c2b ("scsi: tracing: Fix compile error in trace_array calls when TRACING is disabled")
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Arun Easi <aeasi@marvell.com>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Aashish Sharma <shraash@google.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
The parent's input irq number is wrongly subtracted with 32 instead of
using the exact numbers in:
https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j721s2/interrupt_cfg.html
The GPIO interrupts are not working because of that. The toggling works
fine but interrupts are not firing. Fix the parent's input irq that
specifies the base for parent irq.
Tested for MAIN_GPIO0_6 interrupt on the j721s2 EVM.
Fixes: b8545f9d3a ("arm64: dts: ti: Add initial support for J721S2 SoC")
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://lore.kernel.org/r/20220922072950.9157-1-j-keerthy@ti.com
When checking for nEPT support in KVM, use kvm_get_feature_msr() instead
of vcpu_get_msr() to retrieve KVM's default TRUE_PROCBASED_CTLS and
PROCBASED_CTLS2 MSR values, i.e. don't require a VM+vCPU to query nEPT
support.
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20220927165209.930904-1-dmatlack@google.com
[sean: rebase on merged code, write changelog]
Signed-off-by: Sean Christopherson <seanjc@google.com>
Now that a VM isn't needed to check for nEPT support, assert that KVM
supports nEPT in prepare_eptp() instead of skipping the test, and push
the TEST_REQUIRE() check out to individual tests. The require+assert are
somewhat redundant and will incur some amount of ongoing maintenance
burden, but placing the "require" logic in the test makes it easier to
find/understand a test's requirements and in this case, provides a very
strong hint that the test cares about nEPT.
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20220927165209.930904-1-dmatlack@google.com
[sean: rebase on merged code, write changelog]
Signed-off-by: Sean Christopherson <seanjc@google.com>
Drop kvm_get_supported_cpuid_entry() and its inner helper now that all
known usage can use X86_FEATURE_*, X86_PROPERTY_*, X86_PMU_FEATURE_*, or
the dedicated Family/Model helpers. Providing "raw" access to CPUID
leafs is undesirable as it encourages open coding CPUID checks, which is
often error prone and not self-documenting.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20221006005125.680782-13-seanjc@google.com
Add KVM variants of the x86 Family and Model helpers, and use them in the
PMU event filter test. Open code the retrieval of KVM's supported CPUID
entry 0x1.0 in anticipation of dropping kvm_get_supported_cpuid_entry().
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20221006005125.680782-12-seanjc@google.com
Add dedicated helpers for getting x86's Family and Model, which are the
last holdouts that "need" raw access to CPUID information. FMS info is
a mess and requires not only splicing together multiple values, but
requires doing so conditional in the Family case.
Provide wrappers to reduce the odds of copy+paste errors, but mostly to
allow for the eventual removal of kvm_get_supported_cpuid_entry().
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20221006005125.680782-11-seanjc@google.com
Add an X86_PMU_FEATURE_* framework to simplify probing architectural
events on Intel PMUs, which require checking the length of a bit vector
and the _absence_ of a "feature" bit. Add helpers for both KVM and
"this CPU", and use the newfangled magic (along with X86_PROPERTY_*)
to clean up pmu_event_filter_test.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20221006005125.680782-10-seanjc@google.com
Add X86_PROPERTY_PMU_VERSION and use it in vmx_pmu_caps_test to replace
open coded versions of the same functionality.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20221006005125.680782-9-seanjc@google.com
Add and use x86 "properties" for the myriad AMX CPUID values that are
validated by the AMX test. Drop most of the test's single-usage
helpers so that the asserts more precisely capture what check failed.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20221006005125.680782-8-seanjc@google.com
Extent X86_PROPERTY_* support to KVM, i.e. add kvm_cpu_property() and
kvm_cpu_has_p(), and use the new helpers in kvm_get_cpu_address_width().
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20221006005125.680782-7-seanjc@google.com
Use X86_PROPERTY_MAX_KVM_LEAF to replace the equivalent open coded check
on KVM's maximum paravirt CPUID leaf.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20221006005125.680782-5-seanjc@google.com
Introduce X86_PROPERTY_* to allow retrieving values/properties from CPUID
leafs, e.g. MAXPHYADDR from CPUID.0x80000008. Use the same core code as
X86_FEATURE_*, the primary difference is that properties are multi-bit
values, whereas features enumerate a single bit.
Add this_cpu_has_p() to allow querying whether or not a property exists
based on the maximum leaf associated with the property, e.g. MAXPHYADDR
doesn't exist if the max leaf for 0x8000_xxxx is less than 0x8000_0008.
Use the new property infrastructure in vm_compute_max_gfn() to prove
that the code works as intended. Future patches will convert additional
selftests code.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20221006005125.680782-4-seanjc@google.com
Refactor the X86_FEATURE_* framework to prepare for extending the core
logic to support "properties". The "feature" framework allows querying a
single CPUID bit to detect the presence of a feature; the "property"
framework will extend the idea to allow querying a value, i.e. to get a
value that is a set of contiguous bits in a CPUID leaf.
Opportunistically add static asserts to ensure features are fully defined
at compile time, and to try and catch mistakes in the definition of
features.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20221006005125.680782-3-seanjc@google.com
Add X86_FEATURE_PAE and use it to guesstimate the MAXPHYADDR when the
MAXPHYADDR CPUID entry isn't supported.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20221006005125.680782-2-seanjc@google.com
Add a selftest to exercise the KVM_CAP_EXIT_ON_EMULATION_FAILURE
capability.
This capability is also exercised through
smaller_maxphyaddr_emulation_test, but that test requires
allow_smaller_maxphyaddr=Y, which is off by default on Intel when ept=Y
and unconditionally disabled on AMD when npt=Y. This new test ensures
that KVM_CAP_EXIT_ON_EMULATION_FAILURE is exercised independent of
allow_smaller_maxphyaddr.
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20221102184654.282799-11-dmatlack@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Change smaller_maxphyaddr_emulation_test to expect a #PF(RSVD), rather
than an emulation failure, when TDP is disabled. KVM only needs to
emulate instructions to emulate a smaller guest.MAXPHYADDR when TDP is
enabled.
Fixes: 39bbcc3a4e ("selftests: kvm: Allows userspace to handle emulation errors.")
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20221102184654.282799-10-dmatlack@google.com
[sean: massage comment to talk about having to emulate due to MAXPHYADDR]
Signed-off-by: Sean Christopherson <seanjc@google.com>
Provide the error code on a fault in KVM_ASM_SAFE(), e.g. to allow tests
to assert that #PF generates the correct error code without needing to
manually install a #PF handler. Use r10 as the scratch register for the
error code, as it's already clobbered by the asm blob (loaded with the
RIP of the to-be-executed instruction). Deliberately load the output
"error_code" even in the non-faulting path so that error_code is always
initialized with deterministic data (the aforementioned RIP), i.e to
ensure a selftest won't end up with uninitialized consumption regardless
of how KVM_ASM_SAFE() is used.
Don't clear r10 in the non-faulting case and instead load error code with
the RIP (see above). The error code is valid if and only if an exception
occurs, and '0' isn't necessarily a better "invalid" value, e.g. '0'
could result in false passes for a buggy test.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20221102184654.282799-9-dmatlack@google.com
Clear R9 in the non-faulting path of KVM_ASM_SAFE() and fall through to
to a common load of "vector" to effectively load "vector" with '0' to
reduce the code footprint of the asm blob, to reduce the runtime overhead
of the non-faulting path (when "vector" is stored in a register), and so
that additional output constraints that are valid if and only if a fault
occur are loaded even in the non-faulting case.
A future patch will add a 64-bit output for the error code, and if its
output is not explicitly loaded with _something_, the user of the asm
blob can end up technically consuming uninitialized data. Using a
common path to load the output constraints will allow using an existing
scratch register, e.g. r10, to hold the error code in the faulting path,
while also guaranteeing the error code is initialized with deterministic
data in the non-faulting patch (r10 is loaded with the RIP of
to-be-executed instruction).
Consuming the error code when a fault doesn't occur would obviously be a
test bug, but there's no guarantee the compiler will detect uninitialized
consumption. And conversely, it's theoretically possible that the
compiler might throw a false positive on uninitialized data, e.g. if the
compiler can't determine that the non-faulting path won't touch the error
code.
Alternatively, the error code could be explicitly loaded in the
non-faulting path, but loading a 64-bit memory|register output operand
with an explicitl value requires a sign-extended "MOV imm32, r/m64",
which isn't exactly straightforward and has a largish code footprint.
And loading the error code with what is effectively garbage (from a
scratch register) avoids having to choose an arbitrary value for the
non-faulting case.
Opportunistically remove a rogue asterisk in the block comment.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20221102184654.282799-8-dmatlack@google.com
