On Fri, 15 May 2020 14:12:05 -0400 Eric Farman <farman@xxxxxxxxxxxxx> wrote: > >>> Also why do we see the scenario you describe in the wild? I agree that > >>> this should be taken care of in the kernel as well, but according to my > >>> understanding QEMU is already supposed to reject the second SSCH (CPU 2) > >>> with cc 2 because it sees that FC clear function is set. Or? > >> > >> Maybe for virtio, but for vfio this all gets passed through to the > >> kernel who makes that distinction. And as I've mentioned above, that's > >> not happening. > > > > Let's have a look at the following qemu functions. AFAIK it is > > common to vfio and virtio, or? Will prefix my inline > > My mistake, I didn't look far enough up the callchain in my quick look > at the code. > > ...snip... > No problem. I'm glad I was at least little helpful. > > > > So unless somebody (e.g. the kernel vfio-ccw) nukes the FC bits qemu > > should prevent the second SSCH from your example getting to the kernel, > > or? > > It's not so much something "nukes the FC bits" ... but rather that that > the data in the irb_area of the io_region is going to reflect what the > subchannel told us for the interrupt. This is why the word composition came into my mind. If the HW subchannel has FC clear, but QEMU subchannel does not the way things compose (or superpose) is fishy. > > Hrm... If something is polling on TSCH instead of waiting for a tap on > the shoulder, that's gonna act weird too. Maybe the bits need to be in > io_region.irb_area proper, rather than this weird private->scsw space. Do we agree that the scenario you described with that diagram should not have hit kernel in the first place, because if things were correct QEMU should have fenced the second SSCH? I think you do, but want to be sure. If not, then we need to meditate some more on this. I do tend to think that the kernel part is not supposed to rely on userspace playing nice. Especially when it comes to integrity and correctness. I can't tell just yet if this is something we must or just can catch in the kernel module. I'm for catching it regardless, but I'm even more for everything working as it is supposed. :) Regards, Halil
