On 11/26/2013 06:11 PM, Michael S. Tsirkin wrote:
On Tue, Nov 26, 2013 at 06:06:26PM +0200, Avi Kivity wrote:
On 11/26/2013 05:58 PM, Paolo Bonzini wrote:
Il 26/11/2013 16:35, Avi Kivity ha scritto:
If we want to ensure, we need to use a different mechanism for
synchronization than the global RCU. QRCU would work; readers are not
wait-free but only if there is a concurrent synchronize_qrcu, which
should be rare.
An alternative path is to convince ourselves that the hardware does not
provide the guarantees that the current code provides, and so we can
relax them.
No, I think it's a reasonable guarantee to provide.
Why?
Because IIUC the semantics may depend not just on the interrupt
controller, but also on the specific PCI device. It seems safer to
assume that at least one device/driver pair wants this to work.
It's indeed safe, but I think there's a nice win to be had if we
drop the assumption.
I'm not arguing with that, but a minor commoent below:
(BTW, PCI memory writes are posted, but configuration writes are not).
MSIs are configured via PCI memory writes.
By itself, that doesn't buy us anything, since the guest could flush
the write via a read. But I think the fact that the interrupt
messages themselves are posted proves that it is safe.
FYI, PCI read flushes the interrupt itself in, too.
I guess that kills the optimization then. Maybe you can do qrcu,
whatever that is.
--
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
