> From: Michael S. Tsirkin <m...@redhat.com> > Sent: Thursday, June 22, 2023 12:47 PM
> > The hardware footprint of keeping this in memory is also fairly small :) I > care > about a messy interface because this mess builds up over time. > It is really a simple GET command. It is actually messy for the device to implement functionality in two places in cfg space and cvq. > And I am worried about capabilities really. My bad that I missed this change > in > v13. I only can say in my defence that I already had to rewrite huge chunks of > this proposal to make it readable so one can't say I'm only delaying things, > I also > made an effort to help this progress faster :) > > I feel we need a single place where device capabilities can live. So far they > were > in config space. It's consistent, yes I get this has hardware costs *if* > there's a > huge number of VFs and *if* there's a way to provision each VF with a > different > configuration. All the ifs are valid today. > And yes querying VFs over MMIO is kind of ugly. But it does at > least work, and works fine while VF is assigned. So we can build migration > around that *today*. > Other way to say migration can be skipped for this feature bit, and it still works for rest. > But querying over cvq while VF is assigned clearly *doesn't* work. > That is not the idea at all. Querying VF capabilities is the role of the admin command for which we built it. > So what is the solution proposed for this? > 1. Query member device capabilities via admin command > Yes the current migration is broken in many ways but that's what we have. > Let's > build something better sure but that is not 1.3 material. True, it is not 1.3 material, hence the proposal was to have the GET command. Once/if we reach agreement that no new fields to be added to config space starting 1.4 and should be queried using non intercepted cfgvq, it makes sense to let this go in cfg space. Else GET command seems the elegant and right approach.
