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, 
> 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
>  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

>  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

Reply via email to