Re: [Qemu-devel] [PATCH for-2.0] kvm_physical_sync_dirty_bitmap: ignore ENOENT from kvm_vm_ioctl

[Paolo Bonzini]

Il 11/04/2014 22:10, Serge Hallyn ha scritto:
> Quoting Paolo Bonzini (address@hidden):
> > Il 11/04/2014 04:31, Michael Tokarev ha scritto:
> > > ENOENT means the kernel has an empty dirty bitmap for this
> > > slot.  Don't abort in that case.  This appears to solve
> > > the bug reported at
> > >
> > > https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1303926
> > >
> > > which first showed up with commit b533f658a98325d: fix return
> > > check for KVM_GET_DIRTY_LOG ioctl
> > >
> > > Cc: Serge Hallyn <address@hidden>
> > > Signed-off-by: Michael Tokarev <address@hidden>
> > > ---
> > > kvm-all.c |   10 ++++++++--
> > > 1 file changed, 8 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/kvm-all.c b/kvm-all.c
> > > index cd4111d..47fa948 100644
> > > --- a/kvm-all.c
> > > +++ b/kvm-all.c
> > > @@ -441,13 +441,19 @@ static int 
> > > kvm_physical_sync_dirty_bitmap(MemoryRegionSection *section)
> > >
> > >         d.slot = mem->slot;
> > >
> > > -        if (kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d) < 0) {
> > > +        ret = kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d);
> > > +        if (ret >= 0) {
> > > +            /* regular case, process returned bitmap */
> > > +            kvm_get_dirty_pages_log_range(section, d.dirty_bitmap);
> > > +        } else if (ret == -ENOENT) {
> > > +            /* kernel does not have dirty bitmap in this slot */
> > > +            ret = 0;
> > > +        } else {
> > >             DPRINTF("ioctl failed %d\n", errno);
> > >             ret = -1;
> > >             break;
> > >         }
> > >
> > > -        kvm_get_dirty_pages_log_range(section, d.dirty_bitmap);
> > >         start_addr = mem->start_addr + mem->memory_size;
> > >     }
> > >     g_free(d.dirty_bitmap);
> >
> > I'd rather revert b533f658a98325d instead.
>
> That seems wrong though.  If we want to ignore all errors that's one
> thing, but before that commit we just ignored all errors other than
> EPERM.

It is wrong, and the patch would get in again for 2.1 via the KVM tree. 
 But if the patch caused a regression it obviously wasn't trivial 
enough, and so close to 2.0 the safest thing to do is revert it.

Paolo