RE: [PATCH v2 0/2] transport-pci: Introduce legacy registers access using AQ

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Tuesday, May 16, 2023 5:09 PM

> > Possibly one can set. I donât know if any actual device really supported
> endianness.
> > No users have asked for it, even asking explicitly to those non_little_endian
> users.
> 
> For sure, ARM BE does exist and Red Hat supports it because yes, it was
> requested. 
Interesting.
Any vdpa device support this? How is the guest endianness conveyed to this vdpa device?
And which barrier this ARM uses before issuing notification on legacy?

> You can not just go by what marketing tells you today we either try
> to build future proof interfaces or we don't bother at all - by the time these
> things are in the field everything shifted.
> 
Huh.
One can add the BE support incrementally when the device plans to support it.

1.x is already future proof from endianness, so no need to bring endianness for it.
Only legacy can work in the single platform with hw in wider deployment as David acked.
So over engineering is avoided by not introducing BE support.

> > So may be when there is/if a real user, it can be done in future.
> 
> The concern is if you assume LE is default, no way to say "I do not support LE".
> Something like an explicit "SET LE" and "SET BE" commands will automatically
> allow discovering which endian-ness is supported.
> 
This is good suggestion.
The LE for legacy is assumed because barrier etc cannot work.
So, avoiding theoretical spec commands here that may not find any user.

> > > >
> > > > > For any case, having a simple and deterministic device design is
> > > > > always better assuming we've agreed that mediation is a must for
> > > > > legacy drivers. Using dedicated commands can make sure the
> > > > > implementation won't need to go with corner cases of legacy.
> > > > >
> > > > Corner case handling just moved from the device to hypervisor.
> > >
> > > That's not safe, the device should be ready for malicious inputs.
> > >
> > With current offset, register, device will be just fine as most implementations
> have to program control path etc on these registers write/read etc.
> > So, device will be able to handle them with plain 2 commands.
> 
> Except legacy is broken broken broken.  It just does not work for physical
> devices in a crazy number of ways. How about the weird 48 bit limitation on
> PAs? Because no one ever will need any more.
> 
Legacy is broken and works only in small but widely used platform.
Hence, it attempts to support it.

48-bit PA limitation in virtio?

> I have 0 sympathy to this idea of reviving all these bugs then circling back and
> coming up with weird work arounds.  Please, just build a sane transport and
> have software deal with bugs as best it can.
> 
When I proposed the register interface that adheres to the alignment boundary, you suggested to follow legacy semantics.
Now when legacy semantics is followed, you go opposite direction of let sw decide it.

Can we agree that alignment, width and offset to be decided by the sw?