On Mon, May 22, 2017 at 03:30:48AM -0400, Laine Stump wrote: > This reverts commit 2841e675. > > It turns out that adding the host_mtu field to the PCI capabilities in > the guest bumps the length of PCI capabilities beyond the 32 byte > boundary, so the virtio-net device gets 64 bytes of ioport space > instead of 32, which offsets the address of all the other following > devices. Migration doesn't work very well when the location and length > of PCI capabilities of devices is changed between source and > destination. > > This means that we need to make sure that the absence/presence of > host_mtu on the qemu commandline always matches between source and > destination, which means that we need to make setting of host_mtu an > opt-in thing (it can't happen automatically when the bridge being used > has a non-default MTU, which is what commit 2841e675 implemented). > > I do want to re-implement this feature with an <mtu auto='on'/> > setting, but probably won't backport that to any stable branches, so > I'm first reverting the original commit, and that revert can be pushed > to the few releases that have been made since the original (3.1.0 - > 3.3.0) > > Resolves: https://bugzilla.redhat.com/1449346 > --- > src/qemu/qemu_command.c | 32 ++++++++++---------------------- > src/qemu/qemu_command.h | 3 +-- > src/qemu/qemu_hotplug.c | 5 ++--- > src/qemu/qemu_interface.c | 5 ++--- > src/qemu/qemu_interface.h | 3 +-- > 5 files changed, 16 insertions(+), 32 deletions(-) ACK, please push to all relevant branches too Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
