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

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, May 16, 2023 at 09:41:07PM +0000, Parav Pandit wrote:
> 
> > 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?

I don't think, so far.

> And which barrier this ARM uses before issuing notification on legacy?

Would be challenging with hardware, but can work for software virtio
for nested virt I guess?

> > 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.

maybe at least outlike what happens if some device needs to add BE and
drop LE?


> > > > >
> > > > > > 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?

For queue base, yes. One of the crazy things 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.

Sorry if I was unclear.
I was making a distinction between device specific with arbitrary
alignment, where we should just follow legacy semantics, and
common config where I think sw should decide it.


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

For device type specific we can't since spec said we can't :(
For common sure.

-- 
MST