"Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: > On Fri, Oct 12, 2012 at 08:21:50PM +1030, Rusty Russell wrote: >> "Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: >> > On Fri, Oct 12, 2012 at 08:59:36AM +1030, Rusty Russell wrote: >> >> >> 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 > > OK so this means that you also need to track which bytes where written > in order to know to skip byte 2. > This is what I referred to. If instead we ask driver to specify > offset/length explicitly device only needs to remember that. I was assuming the implementation would keep two complete copies of the config space: writes go to the scratch version, which gets copied to the master version upon latch write. But I do wonder if we should just skip this for now, since we don't have any immediate need. Cheers, Rusty. -- 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
