Browse Prior Art Database

Processor centric Sharing of I/O Interrupt Resources

IP.com Disclosure Number: IPCOM000185982D
Original Publication Date: 2009-Aug-04
Included in the Prior Art Database: 2009-Aug-04
Document File: 4 page(s) / 63K

Publishing Venue

IBM

Abstract

Disclosed is a method to increase the number of supported sources of I/O interrupts without enlarging the corresponding hardware resources and without impacting the latency in interrupt handling.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 4

Processor centric Sharing of I/O Interrupt Resources

Background

In today's system z servers interrupts from the outbound I/O adapters get signaled with the help of a hardware facility called PU Attention Vector (PAV). Each bit in the (functional part of the) PAV corresponds to a different interrupt source, which is usually packaged as an I/O card. It gives initiative to look at a 64 bit vector in HSA where the detailed information is kept about the interrupts coming from that specific I/O card. The layout and semantic of the PAV is identical for all processors of the same type (e.g. Central Processing Units (CPUs) or System Assist Processors (SAPs)) as shown in the figure 1 below.

Figure 1: Current interpretation of the PAV

If now the number of attached interrupt sources (i.e. I/O cards) exceeds the size of the PAV, i.e. the number of available bits in the PAV, the following possible solutions are obvious:

I. Increase the PAV in size. This causes a development effort and increases hardware costs.

II. Share one PAV bit between multiple sources of interrupt, i.e. between multiple I/O cards. The drawback of this solution is an increased path length

1

[This page contains 1 picture or other non-text object]

Page 2 of 4

(screening multiple instances of 64 bit vectors) and thus an increased latency in interrupt handling.

The goal is to find a solution which avoids the disadvantages listed there, i.e. which keeps the PAV in size (no hardware development required) and avoids sharing of one PAV bit (no performance penalty).

Summary

The size of a PAV, which exists once per processor, is defined such that each possible source of interrupt in the system, i.e. each I/O card which may get plugged, can get assigned one bit in the PAV. Therefore one always compares the number of possible interrupt sources to the number of bits which are available in one instance of the PU Attention Vector. But when looking at all PAV bits in the system, there are (number of processors)*(number of PAV bits) many bits available in the system which by far exceeds the number of possibly attached sources of interrupts. Therefore the idea is to assign a PAV bit a proces...