On 25 July 2013 10:03, Michael S. Tsirkin <m...@redhat.com> wrote: > On Thu, Jul 25, 2013 at 09:50:21AM +0100, Peter Maydell wrote: >> On 25 July 2013 06:38, Michael S. Tsirkin <m...@redhat.com> wrote: >> > Probably needs to go back to default value on reset? >> >> Tricky, since the default value is "whatever was passed to >> virtio_add_queue()" and we don't save that anywhere. >> >> For virtio-mmio it is a guest bug to fail to write to the >> QueueNum register, so the current behaviour is not out of >> specification (and not harmful either AFAICT). > > Best not to leak info across reboots. > Also if guest sets num = 0 it will cause all kind of > harm, no? > >> I guess we could add a vring.defaultnum, which would be >> set by virtio_add_queue/virtio_del_queue, and have reset >> copy defaultnum into num. No migration needed for defaultnum >> because it's always the same for a particular qemu config.
So I had a look at implementing this, and I noticed that we already have some odd behaviour on reset. Specifically, virtio backends like net can create virtio queues based on guest behaviour (ie setting feature bits). But on reset, these queues aren't deleted, so a post-reset QEMU will look different from a from-scratch restarted QEMU... This in turn makes 'save defaultnum and have reset copy it into num' awkward, because defaultnum now needs to be migrated (otherwise it would do the wrong thing on a reset after a VM migration). -- PMM
