On Wed, 4 Oct 2017 15:49:36 +0200
Pierre Morel <pmo...@linux.vnet.ibm.com> wrote:
> Testing to use Adapter Interrupt suppression or not depend on AIS
> being enabled in the kernel.
> To implement AIS emulation we must move this test inside the FLIC
> dedicated irq_inject function.
>
> Furthermore, a test to verify that the adapter is subject to the AIS
> must be added.
>
> Last, there is no need to crash QEMU if the injection failed, the
> guest may recover from it.
>
> Signed-off-by: Pierre Morel <pmo...@linux.vnet.ibm.com>
> ---
> hw/s390x/css.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/hw/s390x/css.c b/hw/s390x/css.c
> index 901dc6a..6e74a5c 100644
> --- a/hw/s390x/css.c
> +++ b/hw/s390x/css.c
> @@ -672,10 +672,12 @@ void css_adapter_interrupt(CssIoAdapterType type,
> uint8_t isc)
> }
>
> trace_css_adapter_interrupt(isc);
> - if (fs->ais_supported) {
> + /* Use standard IRQ injection for adapters not supporting AIS */
I'd move that comment to the else branch.
> + if (adapter->flags & S390_ADAPTER_SUPPRESSIBLE) {
> + /* Use AIRQ injection for adapters subject to AIS */
> if (fsc->inject_airq(fs, type, isc, adapter->flags)) {
> error_report("Failed to inject airq with AIS supported");
> - exit(1);
> + /* Report error - guest will handle not receiving interrupts */
I'm not 100% sure that this is the right thing to do. I have always
operated under the assumption "if the hardware (host) accepts the I/O,
it owes you an interrupt". (Don't the other failed interrupt injection
paths do a hard stop as well? Is there any reasonable way for an
injection failure to be transient?)
> }
> } else {
> s390_io_interrupt(0, 0, 0, io_int_word);
