On 31.07.2018 10:34, Pierre Morel wrote: > On 30/07/2018 16:40, Halil Pasic wrote: >> >> >> On 07/30/2018 01:15 PM, Pierre Morel wrote: >>> On 30/07/2018 11:24, David Hildenbrand wrote: >>>> On 26.07.2018 21:54, Christian Borntraeger wrote: >>>>> From: Tony Krowiak <akrowiak@xxxxxxxxxxxxx> >>>>> >>>>> Introduces two new KVM interface to lear the APM, AQM and ADM masks in >>>>> the guest's CRYCB. The VCPUs are taken out of SIE to ensure the >>>>> VCPUs do >>>>> not get out of synch. >>>> s/synch/sync/ >>>> >>>> When will this be called and why? >>>> >>>> If I read correctly, this can happen while other VCPUs are running >>>> (currently in the SIE). Please note that >>>> kvm_s390_vcpu_block_all/kvm_s390_vcpu_unblock_all will not care about >>>> vSIE. So a CPU inside the vSIE loop will not be hindered of executing >>>> the SIE. (because so far, all VCPU requests we handle don't rely on >>>> that) >>>> >>>> So it could happen here, that after this call a vSIE CPU still can >>>> access some adapters if we allowed to forward some of them to the >>>> nested >>>> guest. >>> >>> You are right for the principle. >>> >>> However this function is only called when the mediated device is release >>> which is, as we do not support hotplug, when the vfio-device is closed >>> and the guest already disappeared. >>> >>> So I do not think it is useful the way it is currently used. >>> >>> What about just letting this call and function fall and take more >>> time on this problem when we introduce hotplug? >>> >> >> The point is, I don't think we can prohibit userspace to close the >> vfio device before the VM is teared down (hot-unplug). The idea >> was, do the best we can to give up the resources. I was not aware >> of the problems with the VSIE. >> >> QEMU however does make sure there is no hot-unplug. So no user >> can observe the problem. >> >> Halil > > > David, > what about if I extend this function to handle > the SIE when I introduce the SIE in patch 20 > by calling kvm_s390_vsie_kick() ? > SIE kick is not enough. The semantics of that are simply "please exit the SIE to check for any events". It can immediately enter it again reusing the old created crycb block. There would have to be some additional check. But such stuff is usually prone to races. But this patch on its own is not really helpful. It should be introduced along with the caller. (most probably later in this series) > At this patch, we still have no AP in guest 3. > > Pierre > > > -- Thanks, David / dhildenb -- 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
