In case an attribute is used in a subset, the type has to be currently
specified. As the attribute is already defined in the original set, this
is a redundant information in yaml file, moreover, may lead to
inconsistencies.
Example:
attribute-sets:
...
name: pin
enum-name: dpll_a_pin
attributes:
...
-
name: parent-id
type: u32
...
-
name: pin-parent-device
subset-of: pin
attributes:
-
name: parent-id
type: u32 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Remove the requirement from schema files to specify the "type" for
attribute subsets.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Link: https://lore.kernel.org/r/20231006114436.1725425-2-jiri@resnulli.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
`strncpy` is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We expect `app_name` to be NUL-terminated:
dev_info(&oct->pci_dev->dev,
"Running %s (%llu Hz)\n",
app_name, CVM_CAST64(cs->corefreq));
... and it seems NUL-padding is not required, let's opt for strscpy().
For `oct->boardinfo.name/serial_number` let's opt for strscpy() as well
since it is expected to be NUL-terminated and does not require
NUL-padding as `oct` is zero-initialized in octeon_device.c +707:
| buf = vzalloc(size);
| if (!buf)
| return NULL;
|
| oct = (struct octeon_device *)buf;
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://github.com/KSPP/linux/issues/90
Signed-off-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20231005-strncpy-drivers-net-ethernet-cavium-liquidio-octeon_device-c-v1-1-9a207cef9438@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
`strncpy` is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We know `fw_type` must be NUL-terminated based on use here:
| static bool fw_type_is_auto(void)
| {
| return strncmp(fw_type, LIO_FW_NAME_TYPE_AUTO,
| sizeof(LIO_FW_NAME_TYPE_AUTO)) == 0;
| }
...and here
| module_param_string(fw_type, fw_type, sizeof(fw_type), 0444);
Let's opt to NUL-pad the destination buffer as well so that we maintain
the same exact behavior that `strncpy` provided here.
A suitable replacement is `strscpy_pad` due to the fact that it
guarantees both NUL-termination and NUL-padding on the destination
buffer.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://github.com/KSPP/linux/issues/90
Signed-off-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20231005-strncpy-drivers-net-ethernet-cavium-liquidio-lio_main-c-v1-1-663e3f1d8f99@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
dsp_chan->name and chan_name points to same block of memory,
because dev_err still needs to be used it,so we need free
it's memory after use to avoid use_after_free.
Fixes: e527adfb9b ("firmware: imx-dsp: Fix an error handling path in imx_dsp_setup_channels()")
Signed-off-by: Hao Ge <gehao@kylinos.cn>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
TQMLS1088a uses a common board layout with TQMLS1043A/TQMLS1046A.
MBLS10XXA is a starterkit baseboard usable for these SOMs.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Gregor Herburger <gregor.herburger@ew.tq-group.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
TQMLS1043A and TQMLS1046A use the LS1043A LS1046A SOC on a common
layout.
MBLS10XXA is a starterkit baseboard usable for both SOMs.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Gregor Herburger <gregor.herburger@ew.tq-group.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The "attr" pointer points to an offset into the "host" struct so it can't
be NULL. Delete the if statement and pull the code in a tab.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/fe3b8fcd-64a7-4887-bddd-32239a88a6a3@moroto.mountain
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The acpi_evaluate_dsm_typed() provides a way to check the type of the
object evaluated by _DSM call. Use it instead of open coded variant.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231002135125.2602895-1-andriy.shevchenko@linux.intel.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
SolidRun now have 2 product lines around NXP Layerscape SoC:
- LX2160A COM Express 7
- LX2162A System on Module
LX2162 is a smaller package and reduced feature set to LX2160A;
LX2162 SoM is also a smaller form factor and reduced feature set to CEX.
Since both product lines are physically incompatible,
the existing group "SolidRun LX2160A based Boards" has been renamed to
include "CEX" in its name, meaning products based on LX2160A COM Express
Module, following this pattern:
"solidrun,<board>", "solidrun,lx2160a-cex", "fsl,lx2160a"
Add DT compatible for both SolidRun LX2162A SoM, and LX2162 Clearfog
boards to a new group based on LX2162A SoM, following this pattern:
"solidrun,<board>", "solidrun,lx2162a-som", "fsl,lx2160a"
Signed-off-by: Josua Mayer <josua@solid-run.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
If a dev command times out, clk_scaling.active_reqs is not decreased which
causes abnormal clock scaling.
It is complicated to handle different dev command timeout cases in both
legacy mode and MCQ mode. Besides, dev cmds are rarely used and the busy
time is short.
Remove clock scaling busy window for dev cmds like we do for UIC or TM cmds
which don't update busy window either.
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
Link: https://lore.kernel.org/r/20231004062454.29165-1-peter.wang@mediatek.com
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The clear TM function error log status was inverted.
Fixes: 4693fad7d6 ("scsi: ufs: core: Log error handler activity")
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
Link: https://lore.kernel.org/r/20231003022002.25578-1-peter.wang@mediatek.com
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
strncpy() is deprecated for use on NUL-terminated destination strings [1]
and as such we should prefer more robust and less ambiguous string
interfaces.
Since all these structs are copied out to userspace let's keep them
NUL-padded by using strscpy_pad() which guarantees NUL-termination of the
destination buffer while also providing the NUL-padding behavior that
strncpy() has.
Let's also opt to use the more idiomatic strscpy() usage of: 'dest, src,
sizeof(dest)' in cases where the compiler can determine the size of the
destination buffer. Do this for all cases of strscpy...() in this file.
To be abundantly sure we don't leak stack data out to user space let's also
change a strscpy() to strscpy_pad(). This strscpy() was introduced in
commit dbe37c71d1 ("scsi: message: fusion: Replace all non-returning
strlcpy() with strscpy()")
Note that since we are creating these structs with a copy_from_user() and
modifying fields and then copying back out to the user it is probably OK
not to explicitly NUL-pad everything as any data leak is probably just data
from the user themselves. If this is too eager, let's opt for strscpy()
which is still in the spirit of removing deprecated strncpy() usage
treewide.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20230927-strncpy-drivers-message-fusion-mptctl-c-v1-1-bb2eddc1743c@google.com
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Tyrel Datwyler <tyreld@linux.ibm.com> says:
This series includes a couple minor fixes, generalization of some code
that is not protocol specific, and a reworking of the way event pool
buffers are accounted for by the driver. This is a precursor to a
series to follow that introduces support for NVMeoF protocol with
ibmvfc.
Link: https://lore.kernel.org/r/20230921225435.3537728-1-tyreld@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The legacy API for setting the TSC is fundamentally broken, and only
allows userspace to set a TSC "now", without any way to account for
time lost between the calculation of the value, and the kernel eventually
handling the ioctl.
To work around this, KVM has a hack which, if a TSC is set with a value
which is within a second's worth of the last TSC "written" to any vCPU in
the VM, assumes that userspace actually intended the two TSC values to be
in sync and adjusts the newly-written TSC value accordingly.
Thus, when a VMM restores a guest after suspend or migration using the
legacy API, the TSCs aren't necessarily *right*, but at least they're
in sync.
This trick falls down when restoring a guest which genuinely has been
running for less time than the 1 second of imprecision KVM allows for in
in the legacy API. On *creation*, the first vCPU starts its TSC counting
from zero, and the subsequent vCPUs synchronize to that. But then when
the VMM tries to restore a vCPU's intended TSC, because the VM has been
alive for less than 1 second and KVM's default TSC value for new vCPU's is
'0', the intended TSC is within a second of the last "written" TSC and KVM
incorrectly adjusts the intended TSC in an attempt to synchronize.
But further hacks can be piled onto KVM's existing hackish ABI, and
declare that the *first* value written by *userspace* (on any vCPU)
should not be subject to this "correction", i.e. KVM can assume that the
first write from userspace is not an attempt to sync up with TSC values
that only come from the kernel's default vCPU creation.
To that end: Add a flag, kvm->arch.user_set_tsc, protected by
kvm->arch.tsc_write_lock, to record that a TSC for at least one vCPU in
the VM *has* been set by userspace, and make the 1-second slop hack only
trigger if user_set_tsc is already set.
Note that userspace can explicitly request a *synchronization* of the
TSC by writing zero. For the purpose of user_set_tsc, an explicit
synchronization counts as "setting" the TSC, i.e. if userspace then
subsequently writes an explicit non-zero value which happens to be within
1 second of the previous value, the new value will be "corrected". This
behavior is deliberate, as treating explicit synchronization as "setting"
the TSC preserves KVM's existing behaviour inasmuch as possible (KVM
always applied the 1-second "correction" regardless of whether the write
came from userspace vs. the kernel).
Reported-by: Yong He <alexyonghe@tencent.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217423
Suggested-by: Oliver Upton <oliver.upton@linux.dev>
Original-by: Oliver Upton <oliver.upton@linux.dev>
Original-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Like Xu <likexu@tencent.com>
Tested-by: Yong He <alexyonghe@tencent.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20231008025335.7419-1-likexu@tencent.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Orange Pi 5 Plus is RK3588 based SBC featuring:
- 2x 2.5G ethernet ports – onboard NIC hooked to PCIe 2.0 interface
- 2x USB 2.0 host ports
- 2x USB 3.0 host ports (exposed over USB 3.0 hub)
- Type-C port featuring USB 2.0/3.0 and Alt-DP mode
- PCIe 2.0/USB 2.0/I2S/I2C/UART on E.KEY socket
- RTC
- ES8388 on-board sound codec – jack in/out, onboard mic, speaker amplifier
- SPI NOR flash
- RGB LED (R is always on)
- IR receiver
- PCIe 3.0 on the bottom for NVMe, etc.
- 40pin GPIO header (with gpio, I2C, SPI, PWM, UART)
- Power, recovery and Mask ROM buttons
- 2x HDMI out, 1x HDMI in
- Slots/connectors for eMMC, uSD card, fan, MIPI CSI/DSI
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Link: https://lore.kernel.org/r/20231008130515.1155664-5-megi@xff.cz
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add devicetree binding documentation for Orange Pi 5 Plus SBC made by
Xunlong.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20231008130515.1155664-4-megi@xff.cz
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The GuC handles the WA, the KMD just needs to set the flag to enable
it on the appropriate platforms.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231006013553.1339418-1-John.C.Harrison@Intel.com
Currently, discad io is treated the same as normal write io, and for
write behind case, io size is limited to:
BIO_MAX_VECS * (PAGE_SIZE >> 9)
For 0.5KB sector size and 4KB PAGE_SIZE, this is just 1MB. For
consequence, if 'WriteMostly' is set to one of the underlying disks,
then diskcard io will be splited into 1MB and it will take a long time
for the diskcard to finish.
Fix this problem by disable write behind for discard io.
Reported-by: Roman Mamedov <rm@romanrm.net>
Closes: https://lore.kernel.org/all/6a1165f7-c792-c054-b8f0-1ad4f7b8ae01@ultracoder.org/
Reported-and-tested-by: Kirill Kirilenko <kirill@ultracoder.org>
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Signed-off-by: Song Liu <song@kernel.org>
Link: https://lore.kernel.org/r/20231007112105.407449-1-yukuai1@huaweicloud.com
Martynas Pumputis says:
====================
The patchset fixes the limitation of bpf_*_fib_lookup() helper, which
prevents it from being used in BPF dataplanes with network interfaces
which have more than one IP addr. See the first patch for more details.
Thanks!
* v2->v3: Address Martin KaFai Lau's feedback
* v1->v2: Use IPv6 stubs to fix compilation when CONFIG_IPV6=m.
====================
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
This patch extends the existing fib_lookup test suite by adding two test
cases (for each IP family):
* Test source IP selection from the egressing netdev.
* Test source IP selection when an IP route has a preferred src IP addr.
Signed-off-by: Martynas Pumputis <m@lambda.lt>
Link: https://lore.kernel.org/r/20231007081415.33502-3-m@lambda.lt
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Extend the bpf_fib_lookup() helper by making it to return the source
IPv4/IPv6 address if the BPF_FIB_LOOKUP_SRC flag is set.
For example, the following snippet can be used to derive the desired
source IP address:
struct bpf_fib_lookup p = { .ipv4_dst = ip4->daddr };
ret = bpf_skb_fib_lookup(skb, p, sizeof(p),
BPF_FIB_LOOKUP_SRC | BPF_FIB_LOOKUP_SKIP_NEIGH);
if (ret != BPF_FIB_LKUP_RET_SUCCESS)
return TC_ACT_SHOT;
/* the p.ipv4_src now contains the source address */
The inability to derive the proper source address may cause malfunctions
in BPF-based dataplanes for hosts containing netdevs with more than one
routable IP address or for multi-homed hosts.
For example, Cilium implements packet masquerading in BPF. If an
egressing netdev to which the Cilium's BPF prog is attached has
multiple IP addresses, then only one [hardcoded] IP address can be used for
masquerading. This breaks connectivity if any other IP address should have
been selected instead, for example, when a public and private addresses
are attached to the same egress interface.
The change was tested with Cilium [1].
Nikolay Aleksandrov helped to figure out the IPv6 addr selection.
[1]: https://github.com/cilium/cilium/pull/28283
Signed-off-by: Martynas Pumputis <m@lambda.lt>
Link: https://lore.kernel.org/r/20231007081415.33502-2-m@lambda.lt
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Merge series from Rob Herring <robh@kernel.org>:
This is a series is part of ongoing clean-ups related to device
matching and DT related implicit includes. Essentially of_device.h has
a bunch of implicit includes and generally isn't needed any nore except
for of_match_device(). As we also generally want to get rid of
of_match_device() as well, I've done that so we're not updating the
includes twice.
SI hardware does not have doorbells at all, however currently the code
will try to do the allocation and thus fail, makes SI AMDGPU not usable.
Fix this failure by skipping doorbells allocation when doorbells count
is zero.
Fixes: 54c30d2a8d ("drm/amdgpu: create kernel doorbell pages")
Reviewed-by: Shashank Sharma <shashank.sharma@amd.com>
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
eDPs fail to light up with seamless boot enabled
[How]
When seamless boot is enabled don't configure dpms_off
in disable_vbios_mode_if_required.
Reviewed-by: Charlene Liu <charlene.liu@amd.com>
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Acked-by: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Daniel Miess <daniel.miess@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
smatch reports:
vfio_combine_iova_ranges() error: uninitialized symbol 'last'.
vfio_combine_iova_ranges() error: potentially dereferencing uninitialized 'comb_end'.
vfio_combine_iova_ranges() error: potentially dereferencing uninitialized 'comb_start'.
These errors are only reachable via invalid input, in the case of
@last when we receive an empty rb-tree or for @comb_{start,end} if the
rb-tree is empty or otherwise fails to produce a second node that
reduces the gap. Add tests with warnings for these cases.
Reported-by: Cong Liu <liucong2@kylinos.cn>
Link: https://lore.kernel.org/all/20230920095532.88135-1-liucong2@kylinos.cn
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Brett Creeley <brett.creeley@amd.com>
Link: https://lore.kernel.org/r/20231002224325.3150842-1-alex.williamson@redhat.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
The recent necessary overhaul [1] of how we represent SMD ICC and RPM
bus clocks changed the way they're connected. The bindings however were
not updated to reflect that. This series tries to address that, while
also making the relevant bindings less convoluted.
Now, instead of referencing RPM SMD bus clocks via clocks=<>, they're
handled internally within the interconnect framework (via direct RPM
calls from there). We still need to allow some "interface" clocks,
which are necessary to access some registers and not managed for us.
[1] https://lore.kernel.org/linux-arm-msm/20230526-topic-smd_icc-v7-0-09c78c175546@linaro.org/
* icc-rpm-dt-bindings
dt-bindings: interconnect: qcom: Introduce qcom,rpm-common
dt-bindings: interconnect: qcom: qcm2290: Remove RPM bus clocks
dt-bindings: interconnect: qcom: Fix and separate out SDM660
dt-bindings: interconnect: qcom: Fix and separate out MSM8996
dt-bindings: interconnect: qcom: Fix and separate out MSM8939
dt-bindings: interconnect: qcom: rpm: Clean up the file
dt-bindings: interconnect: qcom: rpm: Clean up the example
Link: https://lore.kernel.org/r/20230721-topic-icc_bindings-v2-0-e33d5acbf3bd@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Following the recent cleanups and untanglements, remove abusive
direct references to RPM bus clocks, include the rpm-common YAML and
update Georgi's email.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230721-topic-icc_bindings-v2-6-e33d5acbf3bd@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Separate out MSM8939 icc bindings from the common file and fix the
clocks description by removing the wrong internal RPM bus clock
representation that we've been carrying for years.
This was the final one, so also retire the shared file.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230721-topic-icc_bindings-v2-5-e33d5acbf3bd@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Separate out MSM8996 icc bindings from the common file and fix the
clocks description by removing the wrong internal RPM bus clock
representation that we've been carrying for years.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230721-topic-icc_bindings-v2-4-e33d5acbf3bd@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Separate out SDM660 icc bindings from the common file and fix the
clocks description by removing the wrong internal RPM bus clock
representation that we've been carrying for years.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230721-topic-icc_bindings-v2-3-e33d5acbf3bd@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
After the recent reshuffling, bus clocks are no longer exposed as RPM
clocks. Remove the old description.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230721-topic-icc_bindings-v2-2-e33d5acbf3bd@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
When guest MTRRs are updated, zap SPTEs and do zap range calcluation if and
only if KVM's MMU is honoring guest MTRRs, which is the only time that KVM
incorporates the guest's MTRR type into the final memtype.
Suggested-by: Chao Gao <chao.gao@intel.com>
Suggested-by: Sean Christopherson <seanjc@google.com>
Cc: Kai Huang <kai.huang@intel.com>
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
Link: https://lore.kernel.org/r/20230714065156.20375-1-yan.y.zhao@intel.com
[sean: rephrase shortlog]
Signed-off-by: Sean Christopherson <seanjc@google.com>
Zap SPTEs when CR0.CD is toggled if and only if KVM's MMU is honoring
guest MTRRs, which is the only time that KVM incorporates the guest's
CR0.CD into the final memtype.
Suggested-by: Chao Gao <chao.gao@intel.com>
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
Link: https://lore.kernel.org/r/20230714065122.20315-1-yan.y.zhao@intel.com
[sean: rephrase shortlog]
Signed-off-by: Sean Christopherson <seanjc@google.com>
Add helpers to check if KVM honors guest MTRRs instead of open coding the
logic in kvm_tdp_page_fault(). Future fixes and cleanups will also need
to determine if KVM should honor guest MTRRs, e.g. for CR0.CD toggling and
and non-coherent DMA transitions.
Provide an inner helper, __kvm_mmu_honors_guest_mtrrs(), so that KVM can
check if guest MTRRs were honored when stopping non-coherent DMA.
Note, there is no need to explicitly check that TDP is enabled, KVM clears
shadow_memtype_mask when TDP is disabled, i.e. it's non-zero if and only
if EPT is enabled.
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
Link: https://lore.kernel.org/r/20230714065006.20201-1-yan.y.zhao@intel.com
Link: https://lore.kernel.org/r/20230714065043.20258-1-yan.y.zhao@intel.com
[sean: squash into a one patch, drop explicit TDP check massage changelog]
Signed-off-by: Sean Christopherson <seanjc@google.com>
Certain platforms require that some buses (or individual nodes) make
some additional changes to the clock rate formula, throwing in some
magic, Qualcomm-defined coefficients, to account for "inefficiencies".
Add the framework for it and utilize it on a couple SoCs.
* icc-qcom-coefficients
interconnect: qcom: icc-rpm: Add AB/IB calculations coefficients
interconnect: qcom: icc-rpm: Separate out clock rate calulcations
interconnect: qcom: icc-rpm: Let nodes drive their own bus clock
interconnect: qcom: icc-rpm: Check for node-specific rate coefficients
interconnect: qcom: qcm2290: Hook up MAS_APPS_PROC's bus clock
interconnecga qcom: qcm2290: Set AB coefficients
interconnecgg acom: qcm2290: Update EBI channel configuration
interconnect: qcom: sdm660: Set AB/IB coefficients
interconnect: qcom: msm8996: Set AB/IB coefficients
Link: https://lore.kernel.org/r/20230726-topic-icc_coeff-v4-0-c04b60caa467@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
A previous commit updated the verifier to print an accurate failure
message for when someone specifies a nonzero return value from an async
callback. This adds a testcase for validating that the verifier emits
the correct message in such a case.
Signed-off-by: David Vernet <void@manifault.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20231009161414.235829-2-void@manifault.com
The verifier, as part of check_return_code(), verifies that async
callbacks such as from e.g. timers, will return 0. It does this by
correctly checking that R0->var_off is in tnum_const(0), which
effectively checks that it's in a range of 0. If this condition fails,
however, it prints an error message which says that the value should
have been in (0x0; 0x1). This results in possibly confusing output such
as the following in which an async callback returns 1:
At async callback the register R0 has value (0x1; 0x0) should have been in (0x0; 0x1)
The fix is easy -- we should just pass the tnum_const(0) as the correct
range to verbose_invalid_scalar(), which will then print the following:
At async callback the register R0 has value (0x1; 0x0) should have been in (0x0; 0x0)
Fixes: bfc6bb74e4 ("bpf: Implement verifier support for validation of async callbacks.")
Signed-off-by: David Vernet <void@manifault.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20231009161414.235829-1-void@manifault.com
