[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH v3 0/2] Inter-VM shared memory PCI device

From: Avi Kivity
Subject: [Qemu-devel] Re: [PATCH v3 0/2] Inter-VM shared memory PCI device
Date: Thu, 25 Mar 2010 19:48:36 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3

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 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]