Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3 |
|
#
a03b8ab0 |
| 12-Sep-2023 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/ap: re-init AP queues on config on
[ Upstream commit 32d1d9204f8db3360be55e65bd182a1a68f93308 ]
On a state toggle from config off to config on and on the state toggle from checkstop to not che
s390/ap: re-init AP queues on config on
[ Upstream commit 32d1d9204f8db3360be55e65bd182a1a68f93308 ]
On a state toggle from config off to config on and on the state toggle from checkstop to not checkstop the queue's internal states was set but the state machine was not nudged. This did not care as on the first enqueue of a request the state machine kick ran.
However, within an Secure Execution guest a queue is only chosen by the scheduler when it has been bound. But to bind a queue, it needs to run through the initial states (reset, enable interrupts, ...). So this is like a chicken-and-egg problem and the result was in fact that a queue was unusable after a config off/on toggle.
With some slight rework of the handling of these states now the new function _ap_queue_init_state() is called which is the core of the ap_queue_init_state() function but without locking handling. This has the benefit that it can be called on all the places where a (re-)init of the AP queue's state machine is needed.
Fixes: 2d72eaf036d2 ("s390/ap: implement SE AP bind, unbind and associate") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46 |
|
#
386cb81e |
| 11-Aug-2023 |
Holger Dengler <dengler@linux.ibm.com> |
s390/zcrypt_ep11misc: support API ordinal 6 with empty pin-blob
Secure execution guest environments require an empty pinblob in all key generation and unwrap requests. Empty pinblobs are only availa
s390/zcrypt_ep11misc: support API ordinal 6 with empty pin-blob
Secure execution guest environments require an empty pinblob in all key generation and unwrap requests. Empty pinblobs are only available in EP11 API ordinal 6 or higher.
Add an empty pinblob to key generation and unwrap requests, if the AP secure binding facility is available. In all other cases, stay with the empty pin tag (no pinblob) and the current API ordinals.
The EP11 API ordinal also needs to be considered when the pkey module tries to figure out the list of eligible cards for key operations with protected keys in secure execution environment.
These changes are transparent to userspace but required for running an secure execution guest with handling key generate and key derive (e.g. secure key to protected key) correct. Especially using EP11 secure keys with the kernel dm-crypt layer requires this patch.
Co-developed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Holger Dengler <dengler@linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
Revision tags: v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37 |
|
#
5ac8c724 |
| 28-Jun-2023 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/zcrypt: remove CEX2 and CEX3 device drivers
Remove the legacy device driver code for CEX2 and CEX3 cards.
The last machines which are able to handle CEX2 crypto cards are z10 EC first availabl
s390/zcrypt: remove CEX2 and CEX3 device drivers
Remove the legacy device driver code for CEX2 and CEX3 cards.
The last machines which are able to handle CEX2 crypto cards are z10 EC first available 2008 and z10 BC first available 2009. The last machines able to handle a CEX3 crypto card are z196 first available 2010 and z114 first available 2011.
Please note that this does not imply to drop CEX2 and CEX3 support in general. With older kernels on hardware up to the aforementioned machine models these crypto cards will get support by IBM.
The removal of the CEX2 and CEX3 device drivers code opens up some simplifications, for example support for crypto cards without rng support can be removed also.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
#
cada938a |
| 28-Jun-2023 |
Heiko Carstens <hca@linux.ibm.com> |
s390: fix various typos
Fix various typos found with codespell.
Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
|
Revision tags: v6.1.36, v6.4, v6.1.35 |
|
#
0fdcc88b |
| 19-Jun-2023 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/zcrypt: cleanup some debug code
This patch removes most of the debug code which is build in when CONFIG_ZCRYPT_DEBUG is enabled. There is no real exploiter for this code any more and at least o
s390/zcrypt: cleanup some debug code
This patch removes most of the debug code which is build in when CONFIG_ZCRYPT_DEBUG is enabled. There is no real exploiter for this code any more and at least one ioctl fails with this code enabled.
The CONFIG_ZCRYPT_DEBUG kernel config option still makes sense as some debug sysfs entries can get enabled with this and maybe long term a new better designed debug and error injection way will get introduced.
This patch only removes code surrounded by the named kernel config option. This option should by default always be off anyway. The structs and defines removed by the patch have been used only by code surrounded by a CONFIG_ZCRYPT_DEBUG ifdef and thus can be removed also.
In the end this patch removes all the failure-injection possibilities which had been available when the kernel had been build with CONFIG_ZCRYPT_DEBUG. It has never been used that much and was too unflexible anyway.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
show more ...
|
Revision tags: v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17 |
|
#
2d72eaf0 |
| 10-Mar-2023 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/ap: implement SE AP bind, unbind and associate
Implementation of the new functions for SE AP support: bind, unbind and associate. There are two new sysfs attributes for this:
/sys/devices/ap/c
s390/ap: implement SE AP bind, unbind and associate
Implementation of the new functions for SE AP support: bind, unbind and associate. There are two new sysfs attributes for this:
/sys/devices/ap/cardxx/xx.yyyy/se_bind /sys/devices/ap/cardxx/xx.yyyy/se_associate
Writing a 1 into the se_bind attribute triggers the SE AP bind for this AP queue, writing a 0 into does an unbind - that's a reset (RAPQ) with the F bit enabled.
The se_associate attribute needs an integer value in range 0...2^16-1 written in. This is the index into a secrets table feed into the ultravisor. For more details please see the Architecture documents.
These both new ap queue attributes are only visible inside a SE guest with SB (Secure Binding) available.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
Revision tags: v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4 |
|
#
263c8454 |
| 21-Oct-2022 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/ap: introduce low frequency polling possibility
For some events the ap bus needs to poll. For example when an AP queue is reset until the reset is through. Also when no interrupt support is ava
s390/ap: introduce low frequency polling possibility
For some events the ap bus needs to poll. For example when an AP queue is reset until the reset is through. Also when no interrupt support is available (e.g. zVM) there is a need to poll until all requests have been processed and all replies have been delivered.
Polling is done with a high resolution timer by default run with a rate of 4kHz (LPAR) or 666Hz (zVM guest).
For some events (wait for reset complete, wait for irq enabled complete) this is a much too high poll rate which triggers a lot of TAPQ invocations.
This patch introduces the possibility for the state machine functions to return a new wait enum AP_SM_WAIT_LOW_TIMEOUT which gives a hint to the ap_wait() function to eventually set up the timer with a more relaxed timeout value of 25Hz.
This patch also includes a slight rework of the sysfs functions parsing the timer related stuff: Use of kstrtobool and kstrtoul instead of sscanf.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
Revision tags: v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66 |
|
#
08817496 |
| 07-Sep-2022 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/ap: filter ap card functions, new queue functions attribute
With SE SB (Secure Binding) some currently unused and thus always zero bits in the TAPQ GR2 result are now used to show the binding s
s390/ap: filter ap card functions, new queue functions attribute
With SE SB (Secure Binding) some currently unused and thus always zero bits in the TAPQ GR2 result are now used to show the binding state of a queue. So to check if a card has changed the comparing base is exactly this GR2 value shown as 'ap_function' in sysfs (/sys/devices/ap/cardxx/ap_functions). Now there is some queue specific info in this info and so a new mask TAPQ_CARD_FUNC_CMP_MASK is used to filter out only the relevant bits for card compare.
For the same reason now the function bits (including exactly this bind/associate information) need to be exposed to user space now. So tools like lszcrypt can evaluate binding/association state on a queue base. So here comes a new sysfs attribute
/sys/devices/ap/cardxx/xx.yyyy/ap_functions
This sysfs attribute is similar to the already existing ap_functions attribute at ap card level. It shows the upper 32 bits of GR2 from an invocation of TAPQ for this AP queue.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
#
f6047040 |
| 20-Sep-2022 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/ap: exploit new B bit from QCI config info
This patch introduces an update to the ap_config_info struct which is filled with the QCI subfunction. There is a new bit apsb (short 'B') showing if
s390/ap: exploit new B bit from QCI config info
This patch introduces an update to the ap_config_info struct which is filled with the QCI subfunction. There is a new bit apsb (short 'B') showing if the AP secure bind facility is available. The patch also includes a simple function ap_sb_available() wrapping this bit test.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
#
8794c596 |
| 14-Feb-2023 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/zcrypt: rework length information for dqap
The inline ap_dqap function does not return the number of bytes actually written into the message buffer. The calling code inspects the AP message hea
s390/zcrypt: rework length information for dqap
The inline ap_dqap function does not return the number of bytes actually written into the message buffer. The calling code inspects the AP message header to figure out what kind of AP message has been received and pulls the length information from this header. This processing may not work correctly in cases where only a fragment of the reply is received.
With this patch the ap_dqap inline function now returns the number of actually written bytes in the *length parameter. So the calling function has a chance to compare the number of received bytes against what the AP message header length field states. This is especially useful in cases where a message could only get partially received.
The low level reply processing functions needed some rework to be able to catch this new length information and compare it the right way. The rework also deals with some situations where until now the reply length was not correctly calculated and/or set.
All this has been heavily tested as the modifications on the reply length information may affect crypto load.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
#
003d248f |
| 29-Jan-2023 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/zcrypt: make psmid unsigned long instead of long long
Since s390 kernel build does not support 32 bit build any more there is no difference between long and long long. So this patch reworks all
s390/zcrypt: make psmid unsigned long instead of long long
Since s390 kernel build does not support 32 bit build any more there is no difference between long and long long. So this patch reworks all occurrences of psmid (a 64 bit value) to use unsigned long now.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
Revision tags: v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56 |
|
#
0fef40be |
| 15-Jul-2022 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/ap: fix crash on older machines based on QCI info missing
On older z series machines (z12 and older) there is no QCI info available. The AP code took care of this and the AP bus scan then switc
s390/ap: fix crash on older machines based on QCI info missing
On older z series machines (z12 and older) there is no QCI info available. The AP code took care of this and the AP bus scan then switched to simple probing via TAPQ.
With commit 283915850a44 ("s390/ap: notify drivers on config changed and scan complete callbacks") some code was introduced which silently assumed that the QCI info is always available. However, with KVM simulating an older machine (z12) the result was a kernel crash. Funnily the same crash does not happen on LPAR - maybe because NULL is a valid pointer and reading some data from address 0 also works fine.
This fix now improves the code to be aware that the QCI instruction may not be available on older machines and thus the two pointers to QCI info structs may simple be NULL.
However, on a machine not providing the QCI info the two callbacks to the zcrypt device drivers on_config_changed() and on_scan_complete() provide parameters which are pointers to a QCI info struct. These both callbacks are NOT served if there is no QCI info available. The only consumer of these callbacks is the vfio device driver. This driver only supports CEX4 and higher. All physical machines which are able to provide CEX4 cards have QCI support available. So there is no sense in for example fill the QCI info struct by hand with looping over cards and queues and TAPQ each APQN.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Cc: stable@vger.kernel.org Fixes: 283915850a44 ("s390/ap: notify drivers on config changed and scan complete callbacks") Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
show more ...
|
Revision tags: v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33 |
|
#
2004b57c |
| 04-Apr-2022 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/zcrypt: code cleanup
This patch tries to fix as much as possible of the checkpatch.pl --strict findings: CHECK: Logical continuations should be on the previous line CHECK: No space is neces
s390/zcrypt: code cleanup
This patch tries to fix as much as possible of the checkpatch.pl --strict findings: CHECK: Logical continuations should be on the previous line CHECK: No space is necessary after a cast CHECK: Alignment should match open parenthesis CHECK: 'useable' may be misspelled - perhaps 'usable'? WARNING: Possible repeated word: 'is' CHECK: spaces preferred around that '*' (ctx:VxV) CHECK: Comparison to NULL could be written "!msg" CHECK: Prefer kzalloc(sizeof(*zc)...) over kzalloc(sizeof(struct...)...) CHECK: Unnecessary parentheses around resp_type->work CHECK: Avoid CamelCase: <xcRB>
There is no functional change comming with this patch, only code cleanup, renaming, whitespaces, indenting, ... but no semantic change in any way. Also the API (zcrypt and pkey header file) is semantically unchanged.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Jürgen Christ <jchrist@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
Revision tags: v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9 |
|
#
895ae58d |
| 15-Dec-2021 |
Juergen Christ <jchrist@linux.ibm.com> |
s390/zcrypt: Add admask to zcdn
Zcrypt custom devices now support control domain masks. Users can set and modify this mask to allow custom devices to access certain control domains.
Signed-off-by:
s390/zcrypt: Add admask to zcdn
Zcrypt custom devices now support control domain masks. Users can set and modify this mask to allow custom devices to access certain control domains.
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
Revision tags: v5.15.8, v5.15.7, v5.15.6, v5.15.5 |
|
#
383366b5 |
| 23-Nov-2021 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/zcrypt: Support CPRB minor version T7
There is a new CPRB minor version T7 to be supported with this patch. Together with this the functions which extract the CPRB data from userspace and prepa
s390/zcrypt: Support CPRB minor version T7
There is a new CPRB minor version T7 to be supported with this patch. Together with this the functions which extract the CPRB data from userspace and prepare the AP message do now check the CPRB minor version and provide some info in the flag field of the ap message struct for further processing.
The 3 functions doing this job have been renamed to prep_cca_ap_msg, prep_ep11_ap_msg and prep_rng_ap_msg to reflect their job better (old was get..fc).
This patch also introduces two new flags to be used internal with the flag field of the struct ap_message:
AP_MSG_FLAG_USAGE is set when prep_cca_ap_msg or prep_ep11_ap_msg come to the conclusion that this is a ordinary crypto load CPRB (which means T2 for CCA CPRBs and no admin bit for EP11 CPRBs).
AP_MSG_FLAG_ADMIN is set when prep_cca_ap_msg or prep_ep11_ap_msg think, this is an administrative (control) crypto load CPRB (which means T3, T5, T6 or T7 for CCA CPRBs and admin bit set for EP11 CPRBs).
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Jürgen Christ <jchrist@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
Revision tags: v5.15.4, v5.15.3 |
|
#
a7e701db |
| 17-Nov-2021 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/zcrypt: handle checkstopped cards with new state
A crypto card may be in checkstopped state. With this patch this is handled as a new state in the ap card and ap queue structs. There is also a
s390/zcrypt: handle checkstopped cards with new state
A crypto card may be in checkstopped state. With this patch this is handled as a new state in the ap card and ap queue structs. There is also a new card sysfs attribute
/sys/devices/ap/cardxx/chkstop
and a new queue sysfs attribute
/sys/devices/ap/cardxx/xx.yyyy/chkstop
displaying the checkstop state of the card or queue. Please note that the queue's checkstop state is only a copy of the card's checkstop state but makes maintenance much easier.
The checkstop state expressed here is the result of an RC 0x04 (CHECKSTOP) during an AP command, mostly the PQAP(TAPQ) command which is 'testing' the queue.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Jürgen Christ <jchrist@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
#
985214af |
| 16-Nov-2021 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/zcrypt: CEX8S exploitation support
This patch adds CEX8 exploitation support for the AP bus code, the zcrypt device driver zoo and the vfio device driver.
Signed-off-by: Harald Freudenberger <
s390/zcrypt: CEX8S exploitation support
This patch adds CEX8 exploitation support for the AP bus code, the zcrypt device driver zoo and the vfio device driver.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Jürgen Christ <jchrist@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
Revision tags: v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10 |
|
#
28391585 |
| 01-Oct-2021 |
Tony Krowiak <akrowiak@linux.ibm.com> |
s390/ap: notify drivers on config changed and scan complete callbacks
This patch introduces an extension to the ap bus to notify device drivers when the host AP configuration changes - i.e., adapter
s390/ap: notify drivers on config changed and scan complete callbacks
This patch introduces an extension to the ap bus to notify device drivers when the host AP configuration changes - i.e., adapters, domains or control domains are added or removed. When an adapter or domain is added to the host's AP configuration, the AP bus will create the associated queue devices in the linux sysfs device model. Each new type 10 (i.e., CEX4) or newer queue device with an APQN that is not reserved for the default device driver will get bound to the vfio_ap device driver. Likewise, whan an adapter or domain is removed from the host's AP configuration, the AP bus will remove the associated queue devices from the sysfs device model. Each of the queues that is bound to the vfio_ap device driver will get unbound.
With the introduction of hot plug support, binding or unbinding of a queue device will result in plugging or unplugging one or more queues from a guest that is using the queue. If there are multiple changes to the host's AP configuration, it could result in the probe and remove callbacks getting invoked multiple times. Each time queues are plugged into or unplugged from a guest, the guest's VCPUs must be taken out of SIE. If this occurs multiple times due to changes in the host's AP configuration, that can have an undesirable negative affect on the guest's performance.
To alleviate this problem, this patch introduces two new callbacks: one to notify the vfio_ap device driver when the AP bus scan routine detects a change to the host's AP configuration; and, one to notify the driver when the AP bus is done scanning. This will allow the vfio_ap driver to do bulk processing of all affected adapters, domains and control domains for affected guests rather than plugging or unplugging them one at a time when the probe or remove callback is invoked. The two new callbacks are:
void (*on_config_changed)(struct ap_config_info *new_config_info, struct ap_config_info *old_config_info);
This callback is invoked at the start of the AP bus scan function when it determines that the host AP configuration information has changed since the previous scan. This is done by storing an old and current QCI info struct and comparing them. If there is any difference, the callback is invoked.
void (*on_scan_complete)(struct ap_config_info *new_config_info, struct ap_config_info *old_config_info);
The on_scan_complete callback is invoked after the ap bus scan is completed if the host AP configuration data has changed.
Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
Revision tags: v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20 |
|
#
4f8206b8 |
| 01-Feb-2019 |
Tony Krowiak <akrowiak@linux.ibm.com> |
s390/ap: driver callback to indicate resource in use
Introduces a new driver callback to prevent a root user from re-assigning the APQN of a queue that is in use by a non-default host device driver
s390/ap: driver callback to indicate resource in use
Introduces a new driver callback to prevent a root user from re-assigning the APQN of a queue that is in use by a non-default host device driver to a default host device driver and vice versa. The callback will be invoked whenever a change to the AP bus's sysfs apmask or aqmask attributes would result in one or more APQNs being re-assigned. If the callback responds in the affirmative for any driver queried, the change to the apmask or aqmask will be rejected with a device busy error.
For this patch, only non-default drivers will be queried. Currently, there is only one non-default driver, the vfio_ap device driver. The vfio_ap device driver facilitates pass-through of an AP queue to a guest. The idea here is that a guest may be administered by a different sysadmin than the host and we don't want AP resources to unexpectedly disappear from a guest's AP configuration (i.e., adapters and domains assigned to the matrix mdev). This will enforce the proper procedure for removing AP resources intended for guest usage which is to first unassign them from the matrix mdev, then unbind them from the vfio_ap device driver.
Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
#
783f0a3c |
| 04-Jan-2022 |
Tony Krowiak <akrowiak@linux.ibm.com> |
s390/vfio-ap: add s390dbf logging to the vfio_ap_irq_enable function
This patch adds s390dbf logging to the function that executes the PQAP(AQIC) instruction on behalf of the guest to which the queu
s390/vfio-ap: add s390dbf logging to the vfio_ap_irq_enable function
This patch adds s390dbf logging to the function that executes the PQAP(AQIC) instruction on behalf of the guest to which the queue for which interrupts are being enabled or disabled is attached.
Currently, the vfio_ap_irq_enable function sets status response code 06 (notification indicator byte address (nib) invalid) in the status word when the vfio_pin_pages function - called to pin the page containing the nib - returns an error or a different number of pages pinned than requested.
Setting the response code returned to userspace without also logging a message in the kernel makes it impossible to determine whether the response was due to an error detected by the vfio_ap device driver or because the response code was returned by the firmware in response to the PQAP(AQIC) instruction.
In addition to logging a warning for the situation above, this patch adds the following:
* A function to validate the nib address invoked prior to calling the vfio_pin_pages function. This allows for logging a message informing the reader of the reason the page containing the nib can not be pinned if the nib address is not valid. Response code 06 (invalid nib address) will be set in the status word returned to the guest from the instruction.
* Checks the return value from the kvm_s390_gisc_register and logs a message informing the reader of the failure. Status response code 08 (invalid gisa) will be set in the status word returned to the guest from the PQAP(AQIC) instruction.
* Checks the status response code returned from execution of the PQAP(AQIC) instruction and if it indicates an error, logs a message informing the reader.
Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
#
cabebb69 |
| 25-Aug-2021 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/ap: fix state machine hang after failure to enable irq
If for any reason the interrupt enable for an ap queue fails the state machine run for the queue returned wrong return codes to the caller
s390/ap: fix state machine hang after failure to enable irq
If for any reason the interrupt enable for an ap queue fails the state machine run for the queue returned wrong return codes to the caller. So the caller assumed interrupt support for this queue in enabled and thus did not re-establish the high resolution timer used for polling. In the end this let to a hang for the user space process waiting "forever" for the reply.
This patch reworks these return codes to return correct indications for the caller to re-establish the timer when a queue runs without interrupt support.
Please note that this is fixing a wrong behavior after a first failure (enable interrupt support for the queue) failed. However, looks like this occasionally happens on KVM systems.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
#
b5adbbf8 |
| 07-Jun-2021 |
Julian Wiedmann <jwi@linux.ibm.com> |
s390/ap: use the common driver-data pointer
The device struct provides a pointer for driver-private data. Use this in the zcrypt drivers (as vfio_ap already does), and then remove the custom pointer
s390/ap: use the common driver-data pointer
The device struct provides a pointer for driver-private data. Use this in the zcrypt drivers (as vfio_ap already does), and then remove the custom pointer from the AP device structs.
As really_probe() will always clear the drvdata pointer on error, we no longer have to do so ourselves.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
#
c8c68c5f |
| 07-Jun-2021 |
Julian Wiedmann <jwi@linux.ibm.com> |
s390/ap: use the common device_driver pointer
The device struct itself already contains a pointer to its driver. Use this consistently, instead of duplicating it.
Signed-off-by: Julian Wiedmann <jw
s390/ap: use the common device_driver pointer
The device struct itself already contains a pointer to its driver. Use this consistently, instead of duplicating it.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
#
bd39654a |
| 25-Jun-2021 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/AP: support new dynamic AP bus size limit
This patch provides support for new dynamic AP bus message limit with the existing zcrypt device driver and AP bus core code.
There is support for a n
s390/AP: support new dynamic AP bus size limit
This patch provides support for new dynamic AP bus message limit with the existing zcrypt device driver and AP bus core code.
There is support for a new field 'ml' from TAPQ query. The field gives if != 0 the AP bus limit for this card in 4k chunk units. The actual message size limit per card is shown as a new read-only sysfs attribute. The sysfs attribute
/sys/devices/ap/cardxx/max_msg_size
shows the upper limit in bytes used by the AP bus and zcrypt device driver for requests and replies send to and received from this card. Currently up to CEX7 support only max 12kB msg size and thus the field shows 12288 meaning the upper limit of a valid msg for this card is 12kB. Please note that the usable payload is somewhat lower and depends on the msg type and thus the header struct which is to be prepended by the zcrypt dd.
The dispatcher responsible for choosing the right card and queue is aware of the individual card AP bus message limit. So a request is only assigned to a queue of a card which is able to handle the size of the request (e.g. a 14kB request will never go to a max 12kB card). If no such card is found the ioctl will fail with ENODEV.
The reply buffer held by the device driver is determined by the ml field of the TAPQ for this card. If a response from the card exceeds this limit however, the response is not truncated but the ioctl for this request will fail with errno EMSGSIZE to indicate that the device driver has dropped the response because it would overflow the buffer limit.
If the request size does not indicate to the dispatcher that an adapter with extended limit is to be used, a random card will be chosen when no specific card is addressed (ANY addressing). This may result in an ioctl failure when the reply size needs an adapter with extended limit but the randomly chosen one is not capable of handling the broader reply size. The user space application needs to use dedicated addressing to forward such a request only to suitable cards to get requests like this processed properly.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Ingo Tuchscherer <ingo.tuchscherer@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
#
df6f508c |
| 13-Apr-2021 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/ap/zcrypt: notify userspace with online, config and mode info
This patch brings 3 reworked/new uevent changes: * All AP uevents caused by an ap card or queue device now carry an additional ue
s390/ap/zcrypt: notify userspace with online, config and mode info
This patch brings 3 reworked/new uevent changes: * All AP uevents caused by an ap card or queue device now carry an additional uevent env value MODE=<accel|cca|ep11>. Here is an example: KERNEL[1267.301292] add /devices/ap/card0a (ap) ACTION=add DEVPATH=/devices/ap/card0a SUBSYSTEM=ap DEVTYPE=ap_card DEV_TYPE=000D MODALIAS=ap:t0D MODE=ep11 <- this is new SEQNUM=1095 This is true for bind, unbind, add, remove, and change uevents related to ap card or ap queue devices. * On a change of the soft online attribute on a zcrypt queue or card device a new CHANGE uevent is sent with an env value ONLINE=<0|1>. Example uevent: KERNEL[613.067531] change /devices/ap/card09/09.0011 (ap) ACTION=change DEVPATH=/devices/ap/card09/09.0011 SUBSYSTEM=ap ONLINE=0 <- this is new DEVTYPE=ap_queue DRIVER=cex4queue MODE=cca SEQNUM=1070 - On a change of the config state of an zcrypt card device a new CHANGE uevent is sent with an env value CONFIG=<0|1>. Example uevent: KERNEL[876.258680] change /devices/ap/card09 (ap) ACTION=change DEVPATH=/devices/ap/card09 SUBSYSTEM=ap CONFIG=0 <- this is new DEVTYPE=ap_card DRIVER=cex4card DEV_TYPE=000D MODALIAS=ap:t0D MODE=cca SEQNUM=1073 Setting a card config on/off causes the dependent queue devices to follow the config state change and thus uevents informing about the config state change for the queue devices are also emitted.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|