Bug 1961055

Summary:	virtio-net migrate failed from RHEL-AV 8.2 to RHEL-AV 8.5
Product:	Red Hat Enterprise Linux Advanced Virtualization	Reporter:	jingzhao <jinzhao>
Component:	qemu-kvm	Assignee:	Dr. David Alan Gilbert <dgilbert>
qemu-kvm sub component:	Live Migration	QA Contact:	jingzhao <jinzhao>
Status:	CLOSED DUPLICATE	Docs Contact:
Severity:	high
Priority:	high	CC:	chayang, dgilbert, juzhang, leiyang, virt-maint, yanghliu
Version:	8.5	Keywords:	Regression, TestBlocker
Target Milestone:	rc	Flags:	pm-rhel: mirror+
Target Release:	8.5
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-05-25 17:59:49 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1957838
Bug Blocks:

Description jingzhao 2021-05-17 06:14:02 UTC

Description of problem:
virtio-net migrate failed from RHEL-AV 8.2 to RHEL-AV 8.5

(qemu) qemu-kvm: get_pci_config_device: Bad config data: i=0xde read: 2 device: 3 cmask: ff wmask: 0 w1cmask:0
qemu-kvm: Failed to load PCIDevice:config
qemu-kvm: Failed to load virtio-net:virtio
qemu-kvm: error while loading state for instance 0x0 of device '0000:00:02.0:00.0/virtio-net'
qemu-kvm: load of migration failed: Invalid argument


Version-Release number of selected component (if applicable):

src version:
qemu-kvm-4.2.0-19.module+el8.2.0+6296+6b821950.x86_64
4.18.0-193.56.1.el8_2.x86_64

dest version:
qemu-kvm-6.0.0-16.module+el8.5.0+10848+2dccc46d.x86_64
4.18.0-304.7.el8.kpq1.x86_64


How reproducible:
3/3

Steps to Reproduce:
1. Boot qemu with following cmd on src:
/usr/libexec/qemu-kvm -machine pc-q35-rhel8.2.0 -device pcie-root-port,port=0x14,chassis=5,id=pcie-root-port4,bus=pcie.0 -device virtio-net-pci,netdev=hostnet2,id=virtio-net-pci2,mac=00:52:68:26:31:04,bus=pcie-root-port4 -netdev tap,id=hostnet2,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -monitor stdio

2. Boot qemu with appending "-incoming defer" in the dest

3. Migrate from src to dest

Actual results:
migrate failed 

Expected results:
migrate successfully

Additional info:
1. migrate successfully when use qemu-kvm-5.2.0-14.module+el8.4.0+10425+ad586fa5.x86_64

Comment 2 jingzhao 2021-05-19 08:23:58 UTC

Hi Dave

Could you help to take a look at this bz, I am not sure it's the net issue or migrate issue.


Thanks
Jing

Comment 3 Dr. David Alan Gilbert 2021-05-19 08:41:28 UTC

THanks; can you provide from 8.2, 8.4 and 8.5 guests the output of:

   sudo lspci -vvv

Comment 7 Dr. David Alan Gilbert 2021-05-19 10:10:19 UTC

8.5
        Capabilities: [dc] MSI-X: Enable+ Count=4 Masked-
                Vector table: BAR=1 offset=00000000
                PBA: BAR=1 offset=00000800

8.4:
        Capabilities: [dc] MSI-X: Enable+ Count=3 Masked-
                Vector table: BAR=1 offset=00000000
                PBA: BAR=1 offset=00000800

difference in MSI-X count.

Comment 8 Dr. David Alan Gilbert 2021-05-19 10:44:52 UTC

I see the fix for that in the new machine type code; in cohuck's patch for the non-architecture specific hw-compat there's:

> +    /* hw_compat_rhel_8_4 from hw_compat_5_2 */
> +    { "virtio-net-pci", "vectors", "3"},

I think that should do it.

Comment 9 Dr. David Alan Gilbert 2021-05-20 11:33:54 UTC

Please test with: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=36901026

Comment 10 jingzhao 2021-05-21 03:19:10 UTC

(In reply to Dr. David Alan Gilbert from comment #9)
> Please test with:
> https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=36901026

Checked the build and works now

Thanks
Jing

Comment 11 John Ferlan 2021-05-25 17:48:15 UTC

Dave - assigned to you so you can decide whether resolution can be to duplicate to your bug 1957838 or Connie's bug 1951476 which has the change from Comment 8

Comment 12 Dr. David Alan Gilbert 2021-05-25 17:59:49 UTC

I'll go with mine since I'm not sure we'll pick that up unless we have the new x86 machine type in the x86 case.

*** This bug has been marked as a duplicate of bug 1957838 ***