> From: Michael S. Tsirkin <m...@redhat.com> > Sent: Tuesday, May 16, 2023 2:22 AM > > On Mon, May 15, 2023 at 03:59:41PM +0000, Parav Pandit wrote: > > > > > From: Jason Wang <jasow...@redhat.com> > > > Sent: Monday, May 15, 2023 3:31 AM > > > > > > What do we gain from bisecting it? > > > > > > > > > 1) No need to deal with the offset in the hardware > > > > > In context of legacy is doesn’t matter much given that its over AQ. > > Let me give you an example. I feel that device specific config should allow > arbitrary length accesses so that e.g. > mac can be read and written atomically. > > On the other hand, this is not the case for common config. > Why is this not the case with common config? Spec snippet: "When using the legacy interface the driver MAY access the device-specific configuration region using any width accesses"
> I feel we do not need to allow e.g. access to both common config and device > specific one in a single operation, that is just messy. It is just an offset and value. What part bothers you? > Now sure, we can add text > with an explanation, but if instead there's a flag saying "this is common cfg" > or "this is device cfg" then it fall out automatically. > > Is this a deal breaker? No, but note how neither I nor Jason did not think > about > this ahead of the time and the correct usage just falls out of the interface > automatically. This is a mark of a good interface design. Lots of corner > cases > that one has to be careful around is not. It just moves corner case one layer above in multiple software hypervisors and hypervisor is not failing it either on cfg read/writes as expected by the guest. So bisecting is not adding anything extra. Those failure checks are going to be ignored in hypervisor anyway.
