Am 19.09.18 um 00:23 schrieb Halil Pasic: > > > On 09/18/2018 06:59 PM, Tony Krowiak wrote: >> I've discussed this with Halil -- Pierre is out until next week. We >> are in agreement that while these changes are viable, they result in >> a slightly more complicated implementation compared to previous versions >> (e.g. >> kernel v9 QEMU v7), and locks us into a model that may limit design choices >> down the road if/when virtual and/or emulated AP devices are implemented. > > Just want to confirm, that I did slightly change my mind compared to some > weeks > ago regarding the introducing the dynamic toggle in this stage. Back then I > was > like it's good, because it makes the interface complete. After thinking some > more, it appears to me alone it does not buy us (or userspace) a thing. If > userspace wants to emulate the ap instructions in the first place it can just > clear away the KVM_S390_VM_CPU_FEAT_AP bit (if offered) before applying the > cpu > model. And I can't think of an situation where dynamically switching one way > or > the other would make sense without additional kernel interfaces.
The main point is: QEMU does at that stage not know which device will get plugged. Is it a vfio-ap device? Is it an emulated ap device? If there is a dynamic toggle, that can simply be switched when said device is hotplugged (and with no devices, we can for now always rely on the kernel doing it by enabling apie). We can enforce in QEMU all-emulated or all-vfio. Am I missing something? Having that said, I already asked too many dumb questions regarding to AP and learned a lot. I am happy with the CPU model part. If you both think that this interface is the way to go, I will not object. (merely leave that to Christian and Frank, but I assume they will rely on the hard work of all of you). I will respond with my thought about the interface to Tonys mail. -- Thanks, David / dhildenb
