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);