• Harald Freudenberger's avatar
    s390/AP: support new dynamic AP bus size limit · bd39654a
    Harald Freudenberger authored
    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: default avatarHarald Freudenberger <freude@linux.ibm.com>
    Reviewed-by: default avatarIngo Tuchscherer <ingo.tuchscherer@linux.ibm.com>
    Signed-off-by: default avatarVasily Gorbik <gor@linux.ibm.com>
    bd39654a
ap_bus.h 11.9 KB