Thread (4 messages) 4 messages, 2 authors, 2012-10-16

Re: Using PCI config space to indicate config location

flat view

From: Rusty Russell <hidden>
Date: 2012-10-12 09:52:09
Also in: kvm, qemu-devel

"Michael S. Tsirkin" [off-list ref] writes:
On Fri, Oct 12, 2012 at 08:59:36AM +1030, Rusty Russell wrote:
quoted
quoted
quoted
For writes, the standard seems to be a commit latch.  We could abuse the
generation count for this: the driver writes to it to commit config
changes.
I think this will work. There are a couple of things that bother me:

This assumes read accesses have no side effects, and these are sometimes handy.
Also the semantics for write aren't very clear to me.
I guess device must buffer data until generation count write?
This assumes the device has a buffer to store writes,
and it must track each byte written. I kind of dislike this
tracking of accessed bytes. Also, device would need to resolve conflicts
if any in some device specific way.
It should be trivial to implement: you keep a scratch copy of the config
space, and copy it to the master copy when they hit the latch.

Implementation of this will show whether I've missed anything here, I
think.
What I refer to: what happens if driver does:
- write offset 1
- write offset 3
- hit commit latch
- nothing
- nothing
- effect of offset 1 and offset 3 writes

Now, since there's nothing published by the *driver* at the moment
which can't be trivially atomically written, this scheme is overkill
(sure, it means you could do a byte-at-a-time write to some 4-byte
field, but why?).

But perhaps it's overkill: no other bus has this feature, so we'd need a
feature bit for them anyway in future if we create a device which needs
such atomicity.

Cheers,
Rusty.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help