On 01/26/2018 10:41 AM, Cornelia Huck wrote: > On Thu, 25 Jan 2018 14:28:45 +0100 > Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote: > >> From: Michael Mueller <mimu@xxxxxxxxxxxxxxxxxx> >> >> The function returns a pending I/O interrupt with the highest >> priority defined by its ISC. >> >> Together with AIV activation, pending adapter interrupts are >> managed by the GISA IPM. Thus kvm_s390_get_io_int() needs to >> inspect the IPM as well when the interrupt with the highest >> priority has to be identified. >> >> In case classic and adapter interrupts with the same ISC are >> pending, the classic interrupt will be returned first. > > Can this lead to starving? Consider a guest that never enables itself > for I/O interrupts, but collects pending interrupts via tpi. It will > always get the intis for an isc, but not the ai, wouldn't it? Only if it handles the interrupts slower than new ones arrive, in that case you have a problem anyway. When looking at sane configuration, this priority makes sense as the classic interrupts are used for configuration type ccw, while adapter interrupts are for data. You want to get the control changes quickly. In a sane environment nobody would probably put devices with adapter interrupts on the same isc as different devices with only classic interrupts. But looking at your theoretical "tpi only" case. If your statement is correct then you would also starve interrupts with lets say isc 4 when also interrupts with isc3 are pending, since isc3 will always be preferred. And it did not seem to be an issue in the real world. Or did I miss your point? > >> >> Signed-off-by: Michael Mueller <mimu@xxxxxxxxxxxxxxxxxx> >> Reviewed-by: Halil Pasic <pasic@xxxxxxxxxxxxxxxxxx> >> Reviewed-by: Christian Borntraeger <borntraeger@xxxxxxxxxx> >> Signed-off-by: Christian Borntraeger <borntraeger@xxxxxxxxxx> >> --- >> arch/s390/kvm/interrupt.c | 71 +++++++++++++++++++++++++++++++++++++++++++---- >> 1 file changed, 65 insertions(+), 6 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
