On Tue, Oct 16, 2012 at 11:45:41PM +1030, Rusty Russell wrote: > "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. Yes but config space has some host modifiable registers too. So host needs to be careful to avoid overwriting these. If accesses have side effects that of course breaks too ... > But I do wonder if we should just skip this for now, since we don't > have any immediate need. > > Cheers, > Rusty. MAC setting from guest needs this right now, no? -- MST -- 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
