On 03/25/2010 07:35 PM, Cam Macdonell wrote:
Ah, I see. You adjusted for the different behaviours in the driver.
Still I recommend dropping the status register: this allows single-msi and
PIRQ to behave the same way. Also it is racy, if two guests signal a third,
they will overwrite each other's status.
With shared interrupts with PIRQ without a status register how does a
device know it generated the interrupt?
Right, you need a status register. Just don't add any more information,
since MSI cannot carry any data.
Eventfd values are a counter, not a register. A read() on the other side
returns the sum of all write()s (or eventfd_signal()s). In the context of
irqfd it just means the number of interrupts we coalesced.
Multivalue was considered at one time for a different need and rejected.
Really, to solve the race you need a queue, and that can only be done in
the shared memory segment using locked instructions.
I had a hunch it was probably considered. That explains why irqfd
doesn't have a datamatch field. I guess supporting multiple MSI
vectors with one doorbell per guest isn't possible if one 1 bit of
information can be communicated.
Actually you can have one doorbell supporting multiple vectors and
guests, simply divide the data value into two bit fields, one for the
vector and one for the guest. A single write gets both values into the
host, which can then use datamatch to trigger the correct eventfd (which
is wired to an irqfd in another guest).
So, ioeventfd/irqfd restricts MSI to 1 vector between guests. Should
multi-MSI even be supported then in the non-ioeventfd/irq case?
Otherwise ioeventfd/irqfd become more than an implementation detail.
I lost you. Please re-explain.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
