On 5/15/20 2:37 PM, Halil Pasic wrote: > 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 think I do too. :) I'll meditate on this a bit later, because... > > I do tend to think that the kernel part is not supposed to rely on > userspace playing nice. ...this is important, and I'd rather get the kernel buttoned up first before sorting out QEMU. 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 >
