Displaying 3 results from an estimated 3 matches for "vtcfg_isr_conf_chang".
Did you mean:
vtcfg_isr_conf_changed
2014 Sep 21
2
[PATCH RFC] virtio-pci: share config interrupt between virtio devices
On Sunday 21 September 2014 11:09:14, Michael S. Tsirkin wrote:
> On Thu, Sep 18, 2014 at 09:18:37PM +0200, Stefan Fritsch wrote:
> > On Monday 01 September 2014 09:37:30, Michael S. Tsirkin wrote:
> > > Why do we need INT#x?
> > > How about setting IRQF_SHARED for the config interrupt
> > > while using MSI-X? You'd have to read ISR to check that the
>
2014 Sep 21
2
[PATCH RFC] virtio-pci: share config interrupt between virtio devices
On Sunday 21 September 2014 11:09:14, Michael S. Tsirkin wrote:
> On Thu, Sep 18, 2014 at 09:18:37PM +0200, Stefan Fritsch wrote:
> > On Monday 01 September 2014 09:37:30, Michael S. Tsirkin wrote:
> > > Why do we need INT#x?
> > > How about setting IRQF_SHARED for the config interrupt
> > > while using MSI-X? You'd have to read ISR to check that the
>
2014 Sep 21
0
[PATCH RFC] virtio-pci: share config interrupt between virtio devices
...mentation that comes to mind is virtualbox. But from a quick
> look at the source, it seems that it sets the ISR bit always, too. And
> it uses qemu's subsystem vendor id.
>
> But there are other implementations. For example bhyve.
I couldn't find any code in bhyve that sets VTCFG_ISR_CONF_CHANGED.
Maybe it doesn't generate config changed interrupts?
bhyve sets subsystem vendor to 0 apparently?
We could use that to detect it.
But maybe we should just make it a 1.0 only feature.
>
> > AFAIK a subsystem vendor id does not cost money to register, but
> > only pci sig me...