On Mon, Sep 11, 2023 at 6:15 PM Michael S. Tsirkin <m...@redhat.com> wrote: > > On Mon, Sep 11, 2023 at 02:30:31PM +0800, Jason Wang wrote: > > Customers don't want to have admin stuff, SR-IOV or PASID in the guest > > in order to migrate a single virtio device in the nest. > > Built an alternative facility to implement admin commands then.
I wonder if it could be built in an efficient way. For example the length of admin commands is not fixed and we don't want to grow MMIO areas as the admin command, this will result in something like VIRTIO_PCI_CAP_PCI_CFG which is sub-optimal (much more registers accesses than simply introducing new fields in common cfg). > The advantage of admin commands is they are nicely contained. If it want to be contained it needs to duplicate the functionality of the existing facilities like common cfg and others (one example is to setup the virtqueue after migration). Otherwise during live migration, we will use both admin commands and existing configuration structure which will end up with more issues. As stated before, the best way is to decouple the basic facilities (states like index, inflight, dirty page) from a specific interface/transport and keep the flexibility at the transport layer. Transport layer can choose to stick to the existing interfaces or implement the admin commands. So we can have two ways in parallel: 1) live migration via the existing transport specific facilities, this allows us to reuse the existing interfaces with minimal extensions or take the advantages of the transport specific facilities like PASID 2) live migration via admin commands, but it needs to invent commands to access existing facilities which is just a new transport interface that LingShan is work (transport over admin commands) Instead of focusing on a solution that only works for a specific setup on a specific transport. Thanks > This proposal is way too intrusive. > > -- > MST > --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
