On Mon, 30 Nov 2015 15:41:20 +0300 Pavel Fedin <p.fe...@samsung.com> wrote:
> Hello! > > > > Thank you for the note, i didn't know about irqchip-specific capability > > > codes. There's the > > > same issue with PowerPC, now i > > > understand why there's no KVM_CAP_IRQCHIP for them. Because they have > > > KVM_CAP_IRQ_MPIC and > > > KVM_CAP_IRQ_XICS, similar to S390. > > > But isn't it just weird? I understand that perhaps we have some real > > > need to distinguish > > > between different irqchip types, but > > > shouldn't the kernel also publish KVM_CAP_IRQCHIP, which stands just for > > > "we support some > > > irqchip virtualization"? > > > May be we should just add this for PowerPC and S390, to make things less > > > ambiguous? > > > > Note that we explicitly need to _enable_ the s390 cap (for > > compatibility). I'd need to recall the exact details but I came to the > > conclusion back than that I could not simply enable KVM_CAP_IRQCHIP for > > s390 (and current qemu would fail to enable the s390 cap if we started > > advertising KVM_CAP_IRQCHIP now). > > OMG... I've looked at the code, what a mess... > If i was implementing this, i'd simply introduce kvm_vm_enable_cap(s, > KVM_CAP_IRQCHIP, 0), > which would be allowed to fail with -ENOSYS, so that backwards compatibility > is kept and an existing API is reused... But, well, > it's already impossible to unscramble an egg... :) > Ok, i think in current situation we could choose one of these ways (both are > based on the fact that it's obvious that irqfd require > IRQCHIP). > a) I look for an alternate way to report KVM_CAP_IRQFD dynamically, and > maybe PowerPC and S390 follow this way. The thing is: _when_ can you report KVM_CAP_IRQFD? It obviously requires an irqchip; but if you need some configuration/enablement beforehand, you'll get different values depending on when you retrieve the cap. So does KVM_CAP_IRQFD mean "irqfds are available in principle" or "everything has been setup for usage of irqfds"? I'd assume the former. > b) I simply drop it as it is, because current qemu knows about the > dependency and does not try to use irqfd without irqchip, > because there's simply no use for them. But, well, perhaps there would be an > exception in vhost, i don't remember testing it. Wouldn't an irqfd emulation cover vhost? > So what shall we do? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
