>> That's exactly my point: >> >> sigpif and pfmfi are actually vsie features. I'd have expected that >> zpcii would be a vsie feature as well. >> >> If interpretation is really more an implementation detail in the >> hypervisor to implement zpci, than an actual guest feature (meaning, the >> guest is able to observe it as if it were a real CPU feature), then we >> most probably want some other way to toggle it (maybe via the machine?). >> >> Example: KVM uses SIGP interpretation based on availability. However, we >> don't toggle it via sigpif. sigpif actually tells the guest that it can >> use the SIGP interpretation facility along with vsie. >> >> You mention "CLP instructions will look different", I'm not sure if that >> should actually be handled via the CPU model. From my gut feeling, zpcii >> should actually be the vsie zpcii support to be implemented in the future. >> > > Well, what I meant was that the CLP response data looks different, > primarily because when interpretation is enabled the guest would get > passthrough of the function handle (which in turn has bits turned off > that force hypervisor intercepts) rather than one that QEMU fabricated. Okay, so more some kind of "the device behaves seems to behave slightly different". > > As far as a machine option, well we still need a mechanism by which > userspace can decide whether it's OK to enable interpretation in the > first place. I guess we can take advantage of the fact that the > capability associated with the ioctl interface can indicate both that > the kernel interface is available + all of the necessary hardware > facilities are available to that host kernel. Yes. > > So I guess we could use that to make a decision to default a machine > setting based upon that (yes if everything is available, no if not). Right, in theory we could enable interpretation whenever possible (kernel indicates support, including HW support). In practice, it would be nice to be able to disable zpci interpretation for debugging purposes. One option is to simply glue it to compat machines. So selecting an older compat machine will disable it. Another option is a e.g., machine property, which can be used to force-disable it (e.g., zpcii-disabled) and let the property always default to false. Third option would simply combine both, making compat machines make zpcii-disable result in "true". > >> >> So I wonder if we could simply always enable zPCI interpretation if >> HW+kernel support is around and we're on a new compat machine? I there >> is a way that migration could break (from old kernel to new kernel), >> we'd have to think about alternatives. > > zpci devices are currently marked unmigratable, so if you want to > migrate you need to detach all of them first anyway today. Okay. So it might be reasonable in the future to simply check on source and migration if zpcii is in the same state if zpci devices are attached to the VM. If not, simply fail migration -- in sane enironments, we'd never get a mismatch. -- Thanks, David / dhildenb
