On Tue, May 16, 2023 at 09:19:02PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <[email protected]>
> > Sent: Tuesday, May 16, 2023 4:58 PM
> 
> > > > 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 mean, what you said above exactly?
> > device-specific configuration excludes common config.
> > 
> > 
> So, what prevents the device to fail AQ command with the error code when 
> alignment/width/size is not right?

Nothing but you then need to specify what is and what isn't right.


> > > > 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?
> > 
> > E.g. that it can cross the coundary between common and device config.
> > 
> This is the legacy transport.
> 
> > Look we didn't build modern because we wanted to make work, we did because
> > legacy is broken.  So either let legacy die already or let's build a sane 
> > interface
> > to emulate it please.
> Almost everyone building virtio device would prefer for legacy to die.
> I am still trying to understand that why bisecting register definition of 
> legacy makes it sane.

Because legacy common config is very evil, do not copy it.
Legacy device config is only bad in minor tolerable ways.

> Device behaves based on the register offset, is fine for the legacy 
> transport, guest driver will make the register accesses anyway it prefers.


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to