On Thu, Jul 25, 2013 at 01:30:15PM +0100, Peter Maydell wrote: > 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...
That's a bug. Thanks for the report. :) > 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 Looks like we'll have to fix the bug first :(
