It's used internally by firmware. Using it in the driver
could conflict with firmware.
Reviewed-by: James Zhu <James.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* kvm-arm64/pkvm/restrict-hypercalls:
: .
: Restrict the use of some hypercalls as well as kexec once
: the protected KVM mode has been initialised.
: .
Documentation: admin-guide: Document side effects when pKVM is enabled
Signed-off-by: Marc Zyngier <maz@kernel.org>
Recent changes to KVM for arm64 has made it impossible for the host to
hibernate or use kexec when protected mode is enabled via the kernel
command line.
There are people who rely on kexec (for example, developers who use kexec
as a quick way to test a new kernel), let's document this change in
behaviour, so it doesn't catch them by surprise and we have a place to
point people to if it does.
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211011153835.291147-1-alexandru.elisei@arm.com
There is no way to change default lan_en and lb_en flags while
adding new rule. Add function that allows changing these flags
on rule determined by rule id and recipe id.
Function checks if the rule is presented on regular rules list or
advance rules list and call the appropriate function to update
rule entry.
As rules with ICE_SW_LKUP_DFLT recipe aren't tracked in a list,
implement function which updates flags without searching for rules
based only on rule id.
Signed-off-by: Michal Swiatkowski <michal.swiatkowski@intel.com>
Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com>
Tested-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Change ICE_SW_LKUP_LAST to ICE_MAX_NUM_RECIPES as for now there also can
be recipes other than the default.
Free all structures created for advanced recipes in cleanup function.
Write a function to clean allocated structures on advanced rule info.
Signed-off-by: Victor Raj <victor.raj@intel.com>
Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com>
Tested-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
To remove advanced rule the same protocols list like in adding should be
send to function. Based on this information list of advanced rules is
searched to find the correct rule id.
Remove advanced rule if it forwards to only one VSI. If it forwards
to list of VSI remove only input VSI from this list.
Introduce function to remove rule by id. It is used in case rule needs to
be removed even if it forwards to the list of VSI.
Allow removing all advanced rules from a particular VSI. It is useful in
rebuilding VSI path.
Co-developed-by: Dan Nowlin <dan.nowlin@intel.com>
Signed-off-by: Dan Nowlin <dan.nowlin@intel.com>
Signed-off-by: Shivanshu Shukla <shivanshu.shukla@intel.com>
Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com>
Tested-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Define dummy packet headers to allow adding advanced rules in HW. This
header is used as admin queue command parameter for adding a rule.
The firmware will extract correct fields and will use them in look ups.
Define each supported packets header and offsets to words used in recipe.
Supported headers:
- MAC + IPv4 + UDP
- MAC + VLAN + IPv4 + UDP
- MAC + IPv4 + TCP
- MAC + VLAN + IPv4 + TCP
- MAC + IPv6 + UDP
- MAC + VLAN + IPv6 + UDP
- MAC + IPv6 + TCP
- MAC + VLAN + IPv6 + TCP
Add code for creating an advanced rule. Rule needs to match defined
dummy packet, if not return error, which means that this type of rule
isn't currently supported.
The first step in adding advanced rule is searching for an advanced
recipe matching this kind of rule. If it doesn't exist new recipe is
created. Dummy packet has to be filled with the correct header field
value from the rule definition. It will be used to do look up in HW.
Support searching for existing advance rule entry. It is used in case
of adding the same rule on different VSI. In this case, instead of
creating new rule, the existing one should be updated with refreshed VSI
list.
Add initialization for prof_res_bm_init flag to zero so that
the possible resource for fv in the files can be initialized.
Co-developed-by: Dan Nowlin <dan.nowlin@intel.com>
Signed-off-by: Dan Nowlin <dan.nowlin@intel.com>
Signed-off-by: Grishma Kotecha <grishma.kotecha@intel.com>
Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com>
Tested-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
These changes introduce code for creating advanced recipes for the
switch in hardware.
There are a couple of recipes already defined in the HW. They apply to
matching on basic protocol headers, like MAC, VLAN, MACVLAN,
ethertype or direction (promiscuous), etc.. If the user wants to match on
other protocol headers (eg. ip address, src/dst port etc.) or different
variation of already supported protocols, there is a need to create
new, more complex recipe. That new recipe is referred as
'advanced recipe', and the filtering rule created on top of that recipe
is called 'advanced rule'.
One recipe can have up to 5 words, but the first word is always reserved
for match on switch id, so the driver can define up to 4 words for one
recipe. To support recipes with more words up to 5 recipes can be
chained, so 20 words can be programmed for look up.
Input for adding recipe function is a list of protocols to support. Based
on this list correct profile is being chosen. Correct profile means
that it contains all protocol types from a list. Each profile have up to
48 field vector words and each of this word have protocol id and offset.
These two fields need to match with input data for adding recipe
function. If the correct profile can't be found the function returns an
error.
The next step after finding the correct profile is grouping words into
groups. One group can have up to 4 words. This is done to simplify
sending recipes to HW (because recipe also can have up to 4 words).
In case of chaining (so when look up consists of more than 4 words) last
recipe will always have results from the previous recipes used as words.
A recipe to profile map is used to store information about which profile
is associate with this recipe. This map is an array of 64 elements (max
number of recipes) and each element is a 256 bits bitmap (max number of
profiles)
Profile to recipe map is used to store information about which recipe is
associate with this profile. This map is an array of 256 elements (max
number of profiles) and each element is a 64 bits bitmap (max number of
recipes)
Signed-off-by: Dan Nowlin <dan.nowlin@intel.com>
Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com>
Tested-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Implement functions to manage profiles and field vectors in hardware.
In hardware, there are up to 256 profiles and each of these profiles can
have 48 field vector words. Each field vector word is described by
protocol id and offset in the packet. To add a new recipe all used
profiles need to be searched. If the profile contains all required
protocol ids and offsets from the recipe it can be used. The driver has
to add this profile to recipe association to tell hardware that newly
added recipe is going to be associated with this profile.
The amount of used profiles depend on the package. To avoid searching
across not used profile, max profile id value is calculated at init flow.
The profile is considered as unused when all field vector words in the
profile are invalid (protocol id 0xff and offset 0x1ff).
Profiles are read from the package section ICE_SID_FLD_VEC_SW. Empty
field vector words can be used for recipe results. Store all unused field
vector words in prof_res_bm. It is a 256 elements array (max number of
profiles) each element is a 48 bit bitmap (max number of field vector
words).
For now, support only non-tunnel profiles type.
Co-developed-by: Grishma Kotecha <grishma.kotecha@intel.com>
Signed-off-by: Grishma Kotecha <grishma.kotecha@intel.com>
Signed-off-by: Dan Nowlin <dan.nowlin@intel.com>
Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com>
Tested-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
The computation of TOHM is off by one bit. This missed bit results in
too low a value for TOHM, which can cause errors in regular memory to
incorrectly report:
EDAC MC0: 1 CE Error at MMIOH area, on addr 0x000000207fffa680 on any memory
Fixes: 50d1bb9367 ("sb_edac: add support for Haswell based systems")
Cc: stable@vger.kernel.org
Reported-by: Meeta Saggi <msaggi@purestorage.com>
Signed-off-by: Eric Badger <ebadger@purestorage.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Link: https://lore.kernel.org/r/20211010170127.848113-1-ebadger@purestorage.com
Some targets, QCA6390 for example, use only one TCL ring, it is better to
initialize only one ring and leave others untouched for such targets.
This is a theoretical fix found during code review, no visible impact.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Baochen Qiang <bqiang@codeaurora.org>
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210914163726.38604-1-jouni@codeaurora.org
When doing "rmmod ath11k_pci", ath11k performs global SOC reset
and MHI reset, where 0 address access is captured by IOMMU. See
log below:
...
[ 133.953860] ath11k_pci 0000:02:00.0: setting mhi state: DEINIT(1)
[ 133.959714] ath11k_pci 0000:02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000a address=0x0 flags=0x0020]
[ 133.973854] ath11k_pci 0000:02:00.0: MHISTATUS 0xff04
[ 133.974095] ath11k_pci 0000:02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000a address=0x0 flags=0x0020]
...
This issue is also observed in SSR process, cause a similar
sequence as above is performed.
Such an invalid access occurs because, during rmmod or SSR, MSI
address is cleared but HW MSI functionality not disabled, thus HW
target is able to raise an MSI transaction with 0 as MSI address.
So it can be fixed by simply disabling MSI before reset. For SSR,
since MSI functionality is still needed after target is brought
back, we need to reenable it.
Also change naming of some interfaces related.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Baochen Qiang <bqiang@codeaurora.org>
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210913180246.193388-5-jouni@codeaurora.org
Changes for ti-sysc driver for improved system suspend and resume
support as some drivers need to be reinitialized on resume. Also
a non-urgent resume warning fix, and dropping of legacy flags for
gpio and sham:
- Fix timekeeping suspended warning on resume. Probably no need to merge
this into fixes as it's gone unnoticed for a while.
- Check for context loss for reinit of a module
- Add add quirk handling to reinit on context loss, and also fix a
build warning it caused
- Add quirk handling to reset on reinit
- Use context loss quirk for gpmc and otg
- Handle otg force-idle quirk even if no driver is loaded
- Drop legacy flags for gpio and sham
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAmFkDlQRHHRvbnlAYXRv
bWlkZS5jb20ACgkQG9Q+yVyrpXPupxAAuSlxw9JrSaovIzirxRJ4iIWBljbz9OJQ
CyVZ1AlcckKG+oYAzczH762FDCDdBUh/IQP5yrFPBkBoYFpdMXQxo6NKG/ya92Ea
95wSF/Hz7qKZvQBO9IWSF86LGt0weCg8WW19hKDLJVHnHAJ+rBRwa+cNgpEBjHvU
ddlTSUO14A4kKYRoXgTXyVlivj6UFpRcnZnCLkJ1TSvzGMJiyC2x8Bb3G5ztrEVy
Bs2H5bySxX7gs+KhH+D7s6KAWz1eVD1SYj0bFJST9Xgq+tqOOvO2Bf83K8a0z2gH
qexhV9Tf4gpwbHwDFcTwpvkyP4t8kvn4UqbCfzOcKYXUvq+PTMMPr1+qQvbCJZZy
jD+GC/xGN4us14M32sXOH0lYGYpk3enqkmfDtop7yYxoBX1XtGNKVK10pPHWbsQ1
fVg0JebakU7gBwaEwon9sZR2fnMeJKyEtf43TnBkwYGgB825W6OpH1lOGVj5FB/1
bOK/kzoemTdlafTA/1a+CyLmhTeVWoVctP4bBH0AgQmOOSvfSrZImjMlqmplyHSi
SiYdvHt47VpgCO1oaj3d1FpfijpO7lKqYS2y/+PrA5hcOWzFC7Q3nClJqWkmaU17
wHWWg1qhXuyGKvnurbamDW4PxtJkjzy1wJq40gSpaZ6mlCUqZqx4N/S8M+PGjqnW
VMXfOKIMxeQ=
=nwPV
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmFkUGYACgkQmmx57+YA
GNnPtw/9FyZnrIJQx4ITjgjXc5zQJkWFYBxaoBk18gVOLlUMcAgyEXeOFYph+e84
SdjTQR0yORlCyCvOzV+4Fy0sY6mva0Br67fpjwROPYrfDJ6hQVp7oWfbm+Y3Zc0W
l15eSNbWCD532Q4bKX/3C6O+qF9FF7pakB85mlYWxRj03ei+N31cVLleLl22c0jl
jCUz5qXIpmhwEw95Uxt47H1Sop7cjxq7LED52zMjzJ6G7zg9klXYXvloYrGdwoNg
A+CTtHMNYoi0oj4HR687W5lDHnZAZL4DB10xavi7oTRUg9FqXHiixuVNeGJsf7di
RpvZ4ON5L8JBSxWQVaSVPXf73zSAJShb/5w0o97YyjBbCJmHHNfyf5DX8NbNiu6k
u3OOmywzTOZakmUvcDihb7NDMWsP1Tz+glVx618Xw7TE0GVRkfRNBhw49/3JTNwm
l5N7NNCF7fO0Rb830y9OIVZMu0VElPUrAKJH2IR4zS5S9F33QNNf+V2JrJI5voMW
tXoTusARaouHkahCPFnrdLjoaNFxOMv1mndU5hYOQwamqg/GDWXlRwG9Ohy1s99n
Rnms0V9c6zTVhtElfKZPLU6vTAaVUFaXV+U/pZq87SCRYBjUFNpO038cM9a8N9FT
xSzt01ClnvYt+zl/nIwAnAkGKx1m66xQJxhlgrhMEDq56QkHa7E=
=2uHl
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v5.16/ti-sysc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/drivers
Driver changes for ti-sysc for v5.16
Changes for ti-sysc driver for improved system suspend and resume
support as some drivers need to be reinitialized on resume. Also
a non-urgent resume warning fix, and dropping of legacy flags for
gpio and sham:
- Fix timekeeping suspended warning on resume. Probably no need to merge
this into fixes as it's gone unnoticed for a while.
- Check for context loss for reinit of a module
- Add add quirk handling to reinit on context loss, and also fix a
build warning it caused
- Add quirk handling to reset on reinit
- Use context loss quirk for gpmc and otg
- Handle otg force-idle quirk even if no driver is loaded
- Drop legacy flags for gpio and sham
* tag 'omap-for-v5.16/ti-sysc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
bus: ti-sysc: Fix variable set but not used warning for reinit_modules
bus: ti-sysc: Drop legacy quirk flag for sham
bus: ti-sysc: Drop legacy quirk flag for gpio
bus: ti-sysc: Handle otg force idle quirk
bus: ti-sysc: Use context lost quirk for otg
bus: ti-sysc: Use context lost quirks for gpmc
bus: ti-sysc: Add quirk handling for reset on re-init
bus: ti-sysc: Add quirk handling for reinit on context lost
bus: ti-sysc: Check for lost context in sysc_reinit_module()
bus: ti-sysc: Fix timekeeping_suspended warning on resume
Link: https://lore.kernel.org/r/pull-1633950030-501948@atomide.com-2
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Add code to manage recipes and profiles on admin queue layer.
Allow the driver to add a new recipe and update an existing one. Get a
recipe and get a recipe to profile association is mostly used in update
existing recipes code.
Only default recipes can be updated. An update is done by reading recipes
from HW, changing their params and calling add recipe command.
Support following admin queue commands:
- ice_aqc_opc_add_recipe (0x0290) - create a recipe with protocol
header information and other details that determine how this recipe
filter works
- ice_aqc_opc_recipe_to_profile (0x0291) - associate a switch recipe
to a profile
- ice_aqc_opc_get_recipe (0x0292) - get details of an existing recipe
- ice_aqc_opc_get_recipe_to_profile (0x0293) - get a recipe associated
with profile ID
Define ICE_AQC_RES_TYPE_RECIPE resource type to hold a switch
recipe. It is needed when a new switch recipe needs to be created.
Co-developed-by: Dan Nowlin <dan.nowlin@intel.com>
Signed-off-by: Dan Nowlin <dan.nowlin@intel.com>
Signed-off-by: Grishma Kotecha <grishma.kotecha@intel.com>
Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com>
Tested-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
SAR information from BIOS may come in non sequential pattern.
To overcome the issue, a check is made to extract the right SAR
information using the device mode which is currently being used.
Remove .owner field if calls are used which set it automatically.
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Shravan S <s.shravan@intel.com>
Link: https://lore.kernel.org/r/20211006073525.1332925-1-s.shravan@intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
SAR information from BIOS may come in non sequential pattern.
To overcome the issue, a check is made to extract the right SAR
information using the device mode which is currently being used.
Remove .owner field if calls are used which set it automatically.
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Shravan S <s.shravan@intel.com>
Link: https://lore.kernel.org/r/20211006073525.1332925-1-s.shravan@intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Fix for this build problem:
drivers/net/ethernet/sun/ldmvsw.c: In function 'vsw_alloc_netdev':
drivers/net/ethernet/sun/ldmvsw.c:243:2: error: expected ';' before 'sprintf'
sprintf(dev->name, "vif%d.%d", (int)handle, (int)port_id);
^~~~~~~
Fixes: a7639279c9 ("ethernet: sun: remove direct netdev->dev_addr writes")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://lore.kernel.org/r/20211011173424.7743035d@canb.auug.org.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fix observed warning:
/builds/linux/arch/sparc/boot/Makefile:35: FORCE prerequisite is missing
Fixes: e1f86d7b4b ("kbuild: warn if FORCE is missing for if_changed(_dep,_rule) and filechk")
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Nicolas Schier <n.schier@avm.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
If this function fails to touch a dummy header due to missing parent
directory, then it creates it and touches the file again.
This was needed because CONFIG_FOO_BAR was previously tracked by
include/config/foo/bar.h. (include/config/foo/ may not exist here)
This is no longer the case since commit 0e0345b77a ("kbuild: redo
fake deps at include/config/*.h"); now all the fake headers are placed
right under include/config/, like include/config/FOO_BAR.
Do not try to create parent directory, include/config/, which already
exists.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The if ... else inside the for-loop is unneeded because one empty
line is placed after printing the last element of deps_config.
Currently, all errors in conf_write_dep() are ignored. Add proper
error checks.
Rename it to conf_write_autoconf_cmd(), which is more intuitive.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This function does similar for auto.conf and autoconf.h
Create __conf_write_autoconf() helper to factor out the common code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Now that sym_escape_string_value() is only used in confdata.c
it can be a 'static' function.
Rename it escape_string_value() because it is agnostic about
(struct sym *).
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
We can reuse __print_symbol() helper to print symbols for listnewconfig.
Only the difference is the format for "n" symbols.
This prints "CONFIG_FOO=n" instead of "# CONFIG_FOO is not set".
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
I do not think 'struct conf_printer' is so useful.
Add simple functions, print_symbol_for_*() to write out one symbol.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
All the call sites of conf_write_heading() pass NULL to the third
argument, and it is not used in the function.
Also, the print_comment hooks are doing much more complex than
needed.
Rewrite the code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
dev_err_probe() avoids printing into log when the deferred probe is invoked.
This is possible when clock provider is pending to appear.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211007170250.27997-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The devm_clk_get_optional() helper returns NULL when devm_clk_get()
returns -ENOENT. This makes things slightly cleaner. The added benefit
is mostly cosmetic.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211007170250.27997-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
dev_err_probe() avoids printing into log when the deferred probe is invoked.
This is possible when clock provider is pending to appear.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211007165715.27463-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The devm_clk_get_optional() helper returns NULL when devm_clk_get()
returns -ENOENT. This makes things slightly cleaner. The added benefit
is mostly cosmetic.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211007165715.27463-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use temporary variable for struct device to make code neater.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211007165715.27463-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Access to platform data via dev_get_platdata() getter to make code cleaner.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211007165715.27463-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Protected KVM does not support protected AArch32 guests. However,
it is possible for the guest to force run AArch32, potentially
causing problems. Add an extra check so that if the hypervisor
catches the guest doing that, it can prevent the guest from
running again by resetting vcpu->arch.target and returning
ARM_EXCEPTION_IL.
If this were to happen, The VMM can try and fix it by re-
initializing the vcpu with KVM_ARM_VCPU_INIT, however, this is
likely not possible for protected VMs.
Adapted from commit 22f553842b ("KVM: arm64: Handle Asymmetric
AArch32 systems")
Signed-off-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211010145636.1950948-12-tabba@google.com
Trap accesses to restricted features for VMs running in protected
mode.
Access to feature registers are emulated, and only supported
features are exposed to protected VMs.
Accesses to restricted registers as well as restricted
instructions are trapped, and an undefined exception is injected
into the protected guests, i.e., with EC = 0x0 (unknown reason).
This EC is the one used, according to the Arm Architecture
Reference Manual, for unallocated or undefined system registers
or instructions.
Only affects the functionality of protected VMs. Otherwise,
should not affect non-protected VMs when KVM is running in
protected mode.
Signed-off-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211010145636.1950948-11-tabba@google.com
Move the sanitized copies of the CPU feature registers to the
recently created sys_regs.c. This consolidates all copies in a
more relevant file.
No functional change intended.
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211010145636.1950948-10-tabba@google.com
Protected VMs have more restricted features that need to be
trapped. Moreover, the host should not be trusted to set the
appropriate trapping registers and their values.
Initialize the trapping registers, i.e., hcr_el2, mdcr_el2, and
cptr_el2 at EL2 for protected guests, based on the values of the
guest's feature id registers.
No functional change intended as trap handlers introduced in the
previous patch are still not hooked in to the guest exit
handlers.
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211010145636.1950948-9-tabba@google.com
Add system register handlers for protected VMs. These cover Sys64
registers (including feature id registers), and debug.
No functional change intended as these are not hooked in yet to
the guest exit handlers introduced earlier. So when trapping is
triggered, the exit handlers let the host handle it, as before.
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211010145636.1950948-8-tabba@google.com
Simplify code for hiding MTE support in feature id register when
MTE is not enabled/supported by KVM.
No functional change intended.
Signed-off-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211010145636.1950948-7-tabba@google.com
It's not currently used. Added for completeness.
No functional change intended.
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211010145636.1950948-6-tabba@google.com
We need struct kvm to check for protected VMs to be able to pick
the right handlers for them in subsequent patches.
Signed-off-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211010145636.1950948-5-tabba@google.com
Simplify the early exception handling by slicing the gigantic decoding
tree into a more manageable set of functions, similar to what we have
in handle_exit.c.
This will also make the structure reusable for pKVM's own early exit
handling.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://lore.kernel.org/r/20211010145636.1950948-4-tabba@google.com
hyp-main.c includes switch.h while it only requires adjust-pc.h.
Fix it to remove an unnecessary dependency.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://lore.kernel.org/r/20211010145636.1950948-3-tabba@google.com
In order to avoid including the whole of the switching helpers
in unrelated files, move the __get_fault_info() and related helpers
into their own include file.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://lore.kernel.org/r/20211010145636.1950948-2-tabba@google.com
The int3472-discrete driver can enter an error path after initialising
int3472->clock.ena_gpio, but before it has registered the clock. This will
cause a NULL pointer dereference, because clkdev_drop() is not null aware.
Instead of guarding the call to skl_int3472_unregister_clock() by checking
for .ena_gpio, check specifically for the presence of the clk_lookup, which
will guarantee clkdev_create() has already been called.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214453
Fixes: 7540599a5e ("platform/x86: intel_skl_int3472: Provide skl_int3472_unregister_clock()")
Signed-off-by: Daniel Scally <djrscally@gmail.com>
Link: https://lore.kernel.org/r/20211008224608.415949-1-djrscally@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
