On Wed, Sep 20, 2023 at 8:41 PM Michael S. Tsirkin <m...@redhat.com> wrote: > > On Wed, Sep 20, 2023 at 08:05:49AM -0400, Michael S. Tsirkin wrote: > > On Wed, Sep 20, 2023 at 07:22:32PM +0800, Zhu, Lingshan wrote: > > > > > > > > > On 9/20/2023 6:36 PM, Michael S. Tsirkin wrote: > > > > On Wed, Sep 20, 2023 at 02:06:13PM +0800, Zhu, Lingshan wrote: > > > > > > > > > > On 9/19/2023 2:49 AM, Michael S. Tsirkin wrote: > > > > > > On Mon, Sep 18, 2023 at 06:41:55PM +0000, Parav Pandit wrote: > > > > > > > > Please refer to the code for setting FEATURES_OK. > > > > > > > It wont work when one needs to suspend the device. > > > > > > > There is no point of doing such work over registers as > > > > > > > fundamental framework is over the AQ. > > > > > > Well not really. It's over admin commands. When these were built the > > > > > > intent always was that it's possible to use admin commands through > > > > > > another interface, other than admin queue. Is there a problem > > > > > > implementing admin commands over a memory BAR? For example, I can > > > > > > see > > > > > > an "admin command" capability pointing at a BAR where > > > > > > commands are supplied, and using a new group type referring to > > > > > > device itself. > > > > > I am not sure, if a bar cap would be implemented as a proxy for the > > > > > admin vq > > > > > based live migration. > > > > Not a proxy for a vq in that there's no vq then. > > > I think if the driver sends admin commands through a VF's bar, then > > > VF forwards the admin commands to the PF, it acts like a proxy, > > > or an agent. Anyway it takes admin commands. > > > > Why send them to the PF? They are controlling the VF anyway. > > > > > So the problems we have discussed still exist. > > > > > > > > > then the problems of admin vq LM that we have > > > > > discussed > > > > > still exist. > > > > I freely admit the finer points of this extended flamewar have been lost > > > > on me, and I wager I'm not the only one. I thought you wanted to migrate > > > > the device just by accessing the device itself (e.g. the VF) without > > > > accessing other devices (e.g. the PF), while Parav wants it in a > > > > separate device so the whole of the device itself can passed through to > > > > guest. Isn't this, fundamentally, the issue? > > > we are implementing basic facilities for live migration. > > > > > > We have pointed out lots of issues, there are many discussions with > > > Jason and Parav about the problems in migration by admin vq, for example: > > > security, QOS and nested. > > > > /me shrugs > > Thanks for the summary I guess. Same applies to almost any proposal. > > What would help make progress is an explanation why this has grown into > > a megathread. Do you understand Parav's thoughts well enough to > > summarize them? > > > And Parav same goes for you - can you summarize Zhu Lingshan's position?
The root cause for the long debate is that there are a lot of misunderstandings between each other. This can be seen from Parav's reply. My understanding is it might be better that each side do a summary of the both proposals. Thanks --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org