This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2001312 - [virtio-win][netkvm] Update INFs to insure DMA remapping
Summary: [virtio-win][netkvm] Update INFs to insure DMA remapping
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: virtio-win
Version: 9.0
Hardware: Unspecified
OS: Windows
high
low
Target Milestone: rc
: 9.0
Assignee: Yvugenfi@redhat.com
QA Contact: Wenkang Ji
URL:
Whiteboard:
Depends On: 2073872
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-09-05 13:24 UTC by Yvugenfi@redhat.com
Modified: 2023-09-28 16:36 UTC (History)
10 users (show)

Fixed In Version: virtio-win-prewhql-0.1-211
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-15 07:27:36 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker   RHEL-1215 0 None Migrated None 2023-08-25 17:56:47 UTC
Red Hat Issue Tracker RHELPLAN-96246 0 None None None 2021-09-05 13:27:32 UTC

Description Yvugenfi@redhat.com 2021-09-05 13:24:21 UTC 
Description of problem:
In order for DMA remapping with IOMMU to be supported, a hint regarding driver support should be added to the OS in the INF file:
https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/enabling-dma-remapping-for-device-drivers


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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

How to test:
* Check https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/enabling-dma-remapping-for-device-drivers device manager screenshot for the DAM remapping capability of the installed device. 
* Applicable for Windows 10 (Windows Server 2016) and up
Comment 1 Yvugenfi@redhat.com 2021-09-26 13:49:30 UTC 
https://github.com/virtio-win/kvm-guest-drivers-windows/pull/647
Comment 3 menli@redhat.com 2021-10-13 08:09:48 UTC 
I test with 211 driver with  "iommu device + virtio netkvm device" ,found the guest can not get network ,

and qmo pop up error message:
(qemu) qemu-kvm: unable to start vhost net: 12: falling back on userspace virtio
qemu-kvm: virtio: bogus descriptor or out of resources


qemu command line:
 /usr/libexec/qemu-kvm \
    -name 'avocado-vt-vm3' \
    -machine q35,kernel-irqchip=split  \
    -nodefaults \
    -vga std  \
    -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x3 \
    -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x3.0x1 \
    -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x3.0x2 \
    -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x3.0x3 \
    -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x3.0x4 \
    -device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x3.0x5 \
    -device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x3.0x6 \
    -device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x3.0x7 \
    -device virtio-scsi-pci,id=virtio_scsi_pci1,bus=pci.2 \
    -blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/home/test/win2022-64-virtio-scsi.qcow2,node-name=data_node \
    -blockdev driver=qcow2,node-name=data_disk,file=data_node \
    -device scsi-hd,drive=data_disk,id=disk1,bus=virtio_scsi_pci1.0,serial=kk \
    -m 14336  \
    -smp 2,maxcpus=4 \
    -cpu 'Skylake-Server',hv_stimer,hv_synic,hv_vpindex,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,hv_reenlightenment,hv_stimer_direct,hv_ipi,+kvm_pv_unhalt \
    -device piix3-usb-uhci,id=usb -device usb-tablet,id=input0 \
    -vnc :10  \
    -rtc base=localtime,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off,strict=off \
    -enable-kvm \
    -qmp tcp:0:1231,server,nowait \
    -monitor stdio \
    -drive file=/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on  \
    -drive file=/home/OVMF_VARS.fd,if=pflash,format=raw,unit=1  \
    -object rng-builtin,id=builtin-f4hKqkqk \
    -device virtio-rng-pci,id=virtio-rng-pci-LilC5UtH,rng=builtin-f4hKqkqk,bus=pci.8,iommu_platform=on,ats=on \
    -device intel-iommu,intremap=on,eim=on,device-iotlb=on \
    -device virtio-net-pci,mac=9a:36:83:b6:3d:05,id=idJVpmsF,netdev=id23ZUK6,bus=pci.3  \
    -netdev tap,id=id23ZUK6,vhost=on \

Addition info:
1. remove -device intel-iommu,intremap=on,eim=on,device-iotlb=on \ , guest can get network
2. just change  -device virtio-net-pci to -device e1000e , not hit the issue described above
3. test with 210 driver,  not hit this issue, so it should be a regression issue caused by this patch.


Thanks 
Menghuan
Comment 4 Yvugenfi@redhat.com 2021-10-18 11:06:52 UTC 
(In reply to menli from comment #3)
> I test with 211 driver with  "iommu device + virtio netkvm device" ,found
> the guest can not get network ,
> 
> and qmo pop up error message:
> (qemu) qemu-kvm: unable to start vhost net: 12: falling back on userspace
> virtio
> qemu-kvm: virtio: bogus descriptor or out of resources
> 
> 
> qemu command line:
>  /usr/libexec/qemu-kvm \
>     -name 'avocado-vt-vm3' \
>     -machine q35,kernel-irqchip=split  \
>     -nodefaults \
>     -vga std  \
>     -device
> pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,
> addr=0x3 \
>     -device
> pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x3.0x1 \
>     -device
> pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x3.0x2 \
>     -device
> pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x3.0x3 \
>     -device
> pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x3.0x4 \
>     -device
> pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x3.0x5 \
>     -device
> pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x3.0x6 \
>     -device
> pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x3.0x7 \
>     -device virtio-scsi-pci,id=virtio_scsi_pci1,bus=pci.2 \
>     -blockdev
> driver=file,cache.direct=off,cache.no-flush=on,filename=/home/test/win2022-
> 64-virtio-scsi.qcow2,node-name=data_node \
>     -blockdev driver=qcow2,node-name=data_disk,file=data_node \
>     -device
> scsi-hd,drive=data_disk,id=disk1,bus=virtio_scsi_pci1.0,serial=kk \
>     -m 14336  \
>     -smp 2,maxcpus=4 \
>     -cpu
> 'Skylake-Server',hv_stimer,hv_synic,hv_vpindex,hv_relaxed,
> hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,
> hv_reenlightenment,hv_stimer_direct,hv_ipi,+kvm_pv_unhalt \
>     -device piix3-usb-uhci,id=usb -device usb-tablet,id=input0 \
>     -vnc :10  \
>     -rtc base=localtime,clock=host,driftfix=slew  \
>     -boot order=cdn,once=c,menu=off,strict=off \
>     -enable-kvm \
>     -qmp tcp:0:1231,server,nowait \
>     -monitor stdio \
>     -drive
> file=/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,
> readonly=on  \
>     -drive file=/home/OVMF_VARS.fd,if=pflash,format=raw,unit=1  \
>     -object rng-builtin,id=builtin-f4hKqkqk \
>     -device
> virtio-rng-pci,id=virtio-rng-pci-LilC5UtH,rng=builtin-f4hKqkqk,bus=pci.8,
> iommu_platform=on,ats=on \
>     -device intel-iommu,intremap=on,eim=on,device-iotlb=on \
>     -device
> virtio-net-pci,mac=9a:36:83:b6:3d:05,id=idJVpmsF,netdev=id23ZUK6,bus=pci.3  \
>     -netdev tap,id=id23ZUK6,vhost=on \
> 
> Addition info:
> 1. remove -device intel-iommu,intremap=on,eim=on,device-iotlb=on \ , guest
> can get network
> 2. just change  -device virtio-net-pci to -device e1000e , not hit the issue
> described above
> 3. test with 210 driver,  not hit this issue, so it should be a regression
> issue caused by this patch.
> 
> 
> Thanks 
> Menghuan

Hello Menghuan,

Why virtio-net device done't have ",iommu_platform=on,ats=on" in the command line?

Best regards,
Yan.
Comment 5 menli@redhat.com 2021-10-19 08:20:46 UTC 
(In reply to Yvugenfi from comment #4)
> (In reply to menli from comment #3)
> > I test with 211 driver with  "iommu device + virtio netkvm device" ,found
> > the guest can not get network ,
> > 
> > and qmo pop up error message:
> > (qemu) qemu-kvm: unable to start vhost net: 12: falling back on userspace
> > virtio
> > qemu-kvm: virtio: bogus descriptor or out of resources
> > 
> > 
> > qemu command line:
> >  /usr/libexec/qemu-kvm \
> >     -name 'avocado-vt-vm3' \
> >     -machine q35,kernel-irqchip=split  \
> >     -nodefaults \
> >     -vga std  \
> >     -device
> > pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,
> > addr=0x3 \
> >     -device
> > pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x3.0x1 \
> >     -device
> > pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x3.0x2 \
> >     -device
> > pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x3.0x3 \
> >     -device
> > pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x3.0x4 \
> >     -device
> > pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x3.0x5 \
> >     -device
> > pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x3.0x6 \
> >     -device
> > pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x3.0x7 \
> >     -device virtio-scsi-pci,id=virtio_scsi_pci1,bus=pci.2 \
> >     -blockdev
> > driver=file,cache.direct=off,cache.no-flush=on,filename=/home/test/win2022-
> > 64-virtio-scsi.qcow2,node-name=data_node \
> >     -blockdev driver=qcow2,node-name=data_disk,file=data_node \
> >     -device
> > scsi-hd,drive=data_disk,id=disk1,bus=virtio_scsi_pci1.0,serial=kk \
> >     -m 14336  \
> >     -smp 2,maxcpus=4 \
> >     -cpu
> > 'Skylake-Server',hv_stimer,hv_synic,hv_vpindex,hv_relaxed,
> > hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,
> > hv_reenlightenment,hv_stimer_direct,hv_ipi,+kvm_pv_unhalt \
> >     -device piix3-usb-uhci,id=usb -device usb-tablet,id=input0 \
> >     -vnc :10  \
> >     -rtc base=localtime,clock=host,driftfix=slew  \
> >     -boot order=cdn,once=c,menu=off,strict=off \
> >     -enable-kvm \
> >     -qmp tcp:0:1231,server,nowait \
> >     -monitor stdio \
> >     -drive
> > file=/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,
> > readonly=on  \
> >     -drive file=/home/OVMF_VARS.fd,if=pflash,format=raw,unit=1  \
> >     -object rng-builtin,id=builtin-f4hKqkqk \
> >     -device
> > virtio-rng-pci,id=virtio-rng-pci-LilC5UtH,rng=builtin-f4hKqkqk,bus=pci.8,
> > iommu_platform=on,ats=on \
> >     -device intel-iommu,intremap=on,eim=on,device-iotlb=on \
> >     -device
> > virtio-net-pci,mac=9a:36:83:b6:3d:05,id=idJVpmsF,netdev=id23ZUK6,bus=pci.3  \
> >     -netdev tap,id=id23ZUK6,vhost=on \
> > 
> > Addition info:
> > 1. remove -device intel-iommu,intremap=on,eim=on,device-iotlb=on \ , guest
> > can get network
> > 2. just change  -device virtio-net-pci to -device e1000e , not hit the issue
> > described above
> > 3. test with 210 driver,  not hit this issue, so it should be a regression
> > issue caused by this patch.
> > 
> > 
> > Thanks 
> > Menghuan
> 
> Hello Menghuan,
> 
> Why virtio-net device done't have ",iommu_platform=on,ats=on" in the command
> line?
> 
> Best regards,
> Yan.

Hi Yan，
Actually， when I run virtio-rng iommo related case in auto hit  error and try to debug it and guess it may related to this patch (I missed iommu_platform=on,ats=on with virtio-net device when I debug),so its a coincidence found the issue described above .

I also try 210 driver with the same command line as comment3 , no qemu pop up error message. 

(qemu) qemu-kvm: unable to start vhost net: 12: falling back on userspace virtio
qemu-kvm: virtio: bogus descriptor or out of resources
Comment 6 ybendito 2021-10-19 10:17:44 UTC 
In 210 build the driver does not claim the compatibility with DMA remapping (iommu), so there problem does not happen.
The proper way to run the VM with iommu is to add "iommu_platform=on,ats=on" to every virtio device.
Currently only netkvm INF file is instrumented for iommu (in build 211), but more drivers will be instumented in future.
Comment 7 menli@redhat.com 2021-10-19 10:48:02 UTC 
(In reply to ybendito from comment #6)
> In 210 build the driver does not claim the compatibility with DMA remapping
> (iommu), so there problem does not happen.
> The proper way to run the VM with iommu is to add "iommu_platform=on,ats=on"
> to every virtio device.
> Currently only netkvm INF file is instrumented for iommu (in build 211), but
> more drivers will be instumented in future.

okay, got it, thanks for clarify it~
Comment 8 leidwang@redhat.com 2021-10-20 13:55:32 UTC 
Hi Yan,

Could you take a look at comment2? Thanks in advance!
Comment 10 Yvugenfi@redhat.com 2021-10-25 07:25:55 UTC 
(In reply to leidwang from comment #8)
> Hi Yan,
> 
> Could you take a look at comment2? Thanks in advance!

Yes, you can consider the bug verified.
Comment 11 menli@redhat.com 2021-10-26 01:22:56 UTC 
Hi Yan,

Please help to check comment 9，the issue  seems to related to this patch  , thanks
Comment 12 menli@redhat.com 2021-10-26 06:10:19 UTC 
(In reply to menli from comment #11)
> Hi Yan,
> 
> Please help to check comment 9，the issue  seems to related to this patch  ,
> thanks


The details in comment 9 , only use # nc -C $guest_ip 10022 method to send command can hit the issue.

Whether we can verify the bz first and use a separate bz to track it? or other suggestion?
Comment 13 Yvugenfi@redhat.com 2021-10-26 08:54:54 UTC 
(In reply to menli from comment #12)
> (In reply to menli from comment #11)
> > Hi Yan,
> > 
> > Please help to check comment 9，the issue  seems to related to this patch  ,
> > thanks
> 
> 
> The details in comment 9 , only use # nc -C $guest_ip 10022 method to send
> command can hit the issue.
> 
> Whether we can verify the bz first and use a separate bz to track it? or
> other suggestion?

Please open another BZ for comment 9.

This changes and BZ was for NetKVM only.
Comment 14 menli@redhat.com 2021-10-26 10:01:45 UTC 
(In reply to Yvugenfi from comment #13)
> (In reply to menli from comment #12)
> > (In reply to menli from comment #11)
> > > Hi Yan,
> > > 
> > > Please help to check comment 9，the issue  seems to related to this patch  ,
> > > thanks
> > 
> > 
> > The details in comment 9 , only use # nc -C $guest_ip 10022 method to send
> > command can hit the issue.
> > 
> > Whether we can verify the bz first and use a separate bz to track it? or
> > other suggestion?
> 
> Please open another BZ for comment 9.
> 
> This changes and BZ was for NetKVM only.

actually remove rng device can also detect this issue, So its a regression issue related to "iommu device + virtio netkvm device". update the following details  to make it more clear:


1. start guest with following qemu command line:

 /usr/libexec/qemu-kvm \
    -name 'avocado-vt-vm3' \
    -machine q35,kernel-irqchip=split  \
    -nodefaults \
    -vga std  \
    -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x3 \
    -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x3.0x1 \
    -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x3.0x2 \
    -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x3.0x3 \
    -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x3.0x4 \
    -device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x3.0x5 \
    -device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x3.0x6 \
    -device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x3.0x7 \
   -device virtio-scsi-pci,id=virtio_scsi_pci1,bus=pci.2,disable-legacy=on,disable-modern=false,iommu_platform=on,ats=on  \
    -blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/home/win2022-64-virtio-scsi.qcow2,node-name=data_node \
    -blockdev driver=qcow2,node-name=data_disk,file=data_node \
    -device scsi-hd,drive=data_disk,id=disk1,bus=virtio_scsi_pci1.0,serial=kk \
    -m 14336  \
    -smp 2,maxcpus=4 \
    -cpu 'Skylake-Server',hv_stimer,hv_synic,hv_vpindex,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,hv_reenlightenment,hv_stimer_direct,hv_ipi,+kvm_pv_unhalt \
    -device piix3-usb-uhci,id=usb -device usb-tablet,id=input0 \
    -vnc :10  \
    -rtc base=localtime,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off,strict=off \
    -enable-kvm \
    -qmp tcp:0:1231,server,nowait \
    -monitor stdio \
    -device intel-iommu,intremap=on,eim=on,device-iotlb=on \
    -device virtio-net-pci,mac=9a:36:83:b6:3d:05,id=idJVpmsF,netdev=id23ZUK6,bus=pci.3,disable-legacy=on,disable-modern=false,iommu_platform=on,ats=on  \
    -netdev tap,id=id23ZUK6,vhost=on \
    -drive id=drive_cd1,if=none,snapshot=off,aio=threads,cache=none,media=cdrom,file=/home/kvm_autotest_root/iso/windows/winutils.iso\
    -device ide-cd,id=cd2,drive=drive_cd1,bus=ide.0,unit=0 \


2. connect to guest session: 
# nc -C $guest_ip 10022


Acutual result:

after step2, Return garbled
eg:

[root@dell-per730-47 ~]# nc -C 10.73.74.208 10022
Please wait...
`���Y�a���J0Afd�M����F���� �?����



C:\>ipconfig

Windows IP Configuration

/�����������'��������������M������E
C:\>



Additional info:

1.try the same steps above with 210 driver, no return garbled
2. just remove  -device intel-iommu,intremap=on,eim=on,device-iotlb=on , can not hit this issue, the result like following, So it should be a regression issue related to "iommu device + virtio netkvm device".

[root@dell-per730-47 ~]# nc -C 10.73.74.208 10022
Please wait...
Microsoft Windows [Version 10.0.20348.169]
(c) Microsoft Corporation. All rights reserved.

C:\>ipconfig

Windows IP Configuration


Ethernet adapter Ethernet Instance 0 2:

   Connection-specific DNS Suffix  . : lab.eng.pek2.redhat.com
   Link-local IPv6 Address . . . . . : fe80::20a4:b429:19d4:59aa%8
   IPv4 Address. . . . . . . . . . . : 10.73.74.208
   Subnet Mask . . . . . . . . . . . : 255.255.252.0
   Default Gateway . . . . . . . . . : 10.73.75.254
Comment 15 Qianqian Zhu 2021-10-27 06:19:20 UTC 
Hi Yan,

Would you please help check comment 14 to confirm should we reassign this bz or file a new bz for it?

Regards,
Qianqian
Comment 16 Yvugenfi@redhat.com 2021-10-27 10:11:42 UTC 
(In reply to Qianqian Zhu from comment #15)
> Hi Yan,
> 
> Would you please help check comment 14 to confirm should we reassign this bz
> or file a new bz for it?
> 
> Regards,
> Qianqian
Please re-assign.

Thanks.
Comment 17 Yvugenfi@redhat.com 2021-10-27 10:14:17 UTC 
(In reply to menli from comment #14)
> (In reply to Yvugenfi from comment #13)
> > (In reply to menli from comment #12)
> > > (In reply to menli from comment #11)
> > > > Hi Yan,
> > > > 
> > > > Please help to check comment 9，the issue  seems to related to this patch  ,
> > > > thanks
> > > 
> > > 
> > > The details in comment 9 , only use # nc -C $guest_ip 10022 method to send
> > > command can hit the issue.
> > > 
> > > Whether we can verify the bz first and use a separate bz to track it? or
> > > other suggestion?
> > 
> > Please open another BZ for comment 9.
> > 
> > This changes and BZ was for NetKVM only.
> 
> actually remove rng device can also detect this issue, So its a regression
> issue related to "iommu device + virtio netkvm device". update the following
> details  to make it more clear:
> 
> 
> 1. start guest with following qemu command line:
> 
>  /usr/libexec/qemu-kvm \
>     -name 'avocado-vt-vm3' \
>     -machine q35,kernel-irqchip=split  \
>     -nodefaults \
>     -vga std  \
>     -device
> pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,
> addr=0x3 \
>     -device
> pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x3.0x1 \
>     -device
> pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x3.0x2 \
>     -device
> pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x3.0x3 \
>     -device
> pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x3.0x4 \
>     -device
> pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x3.0x5 \
>     -device
> pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x3.0x6 \
>     -device
> pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x3.0x7 \
>    -device
> virtio-scsi-pci,id=virtio_scsi_pci1,bus=pci.2,disable-legacy=on,disable-
> modern=false,iommu_platform=on,ats=on  \
>     -blockdev
> driver=file,cache.direct=off,cache.no-flush=on,filename=/home/win2022-64-
> virtio-scsi.qcow2,node-name=data_node \
>     -blockdev driver=qcow2,node-name=data_disk,file=data_node \
>     -device
> scsi-hd,drive=data_disk,id=disk1,bus=virtio_scsi_pci1.0,serial=kk \
>     -m 14336  \
>     -smp 2,maxcpus=4 \
>     -cpu
> 'Skylake-Server',hv_stimer,hv_synic,hv_vpindex,hv_relaxed,
> hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,
> hv_reenlightenment,hv_stimer_direct,hv_ipi,+kvm_pv_unhalt \
>     -device piix3-usb-uhci,id=usb -device usb-tablet,id=input0 \
>     -vnc :10  \
>     -rtc base=localtime,clock=host,driftfix=slew  \
>     -boot order=cdn,once=c,menu=off,strict=off \
>     -enable-kvm \
>     -qmp tcp:0:1231,server,nowait \
>     -monitor stdio \
>     -device intel-iommu,intremap=on,eim=on,device-iotlb=on \
>     -device
> virtio-net-pci,mac=9a:36:83:b6:3d:05,id=idJVpmsF,netdev=id23ZUK6,bus=pci.3,
> disable-legacy=on,disable-modern=false,iommu_platform=on,ats=on  \
>     -netdev tap,id=id23ZUK6,vhost=on \
>     -drive
> id=drive_cd1,if=none,snapshot=off,aio=threads,cache=none,media=cdrom,file=/
> home/kvm_autotest_root/iso/windows/winutils.iso\
>     -device ide-cd,id=cd2,drive=drive_cd1,bus=ide.0,unit=0 \
> 
> 
> 2. connect to guest session: 
> # nc -C $guest_ip 10022
> 
> 
> Acutual result:
> 
> after step2, Return garbled
> eg:
> 
> [root@dell-per730-47 ~]# nc -C 10.73.74.208 10022
> Please wait...
> `���Y�a���J0Afd�M����F���� �?����
> 
> 
> 
> C:\>ipconfig
> 
> Windows IP Configuration
> 
> /�����������'��������������M������E
> C:\>
> 
> 
> 
> Additional info:
> 
> 1.try the same steps above with 210 driver, no return garbled
> 2. just remove  -device intel-iommu,intremap=on,eim=on,device-iotlb=on , can
> not hit this issue, the result like following, So it should be a regression
> issue related to "iommu device + virtio netkvm device".
> 
> [root@dell-per730-47 ~]# nc -C 10.73.74.208 10022
> Please wait...
> Microsoft Windows [Version 10.0.20348.169]
> (c) Microsoft Corporation. All rights reserved.
> 
> C:\>ipconfig
> 
> Windows IP Configuration
> 
> 
> Ethernet adapter Ethernet Instance 0 2:
> 
>    Connection-specific DNS Suffix  . : lab.eng.pek2.redhat.com
>    Link-local IPv6 Address . . . . . : fe80::20a4:b429:19d4:59aa%8
>    IPv4 Address. . . . . . . . . . . : 10.73.74.208
>    Subnet Mask . . . . . . . . . . . : 255.255.252.0
>    Default Gateway . . . . . . . . . : 10.73.75.254

Can you please provide the service\application on the guest that opening 10022 port?
Comment 18 menli@redhat.com 2021-10-27 10:44:44 UTC 
hi leidong,

Could you please help to check comment 17?
Comment 19 leidwang@redhat.com 2021-10-28 01:47:12 UTC 
(In reply to Yvugenfi from comment #17)
> (In reply to menli from comment #14)
> > (In reply to Yvugenfi from comment #13)
> > > (In reply to menli from comment #12)
> > > > (In reply to menli from comment #11)
> > > > > Hi Yan,
> > > > > 
> > > > > Please help to check comment 9，the issue  seems to related to this patch  ,
> > > > > thanks
> > > > 
> > > > 
> > > > The details in comment 9 , only use # nc -C $guest_ip 10022 method to send
> > > > command can hit the issue.
> > > > 
> > > > Whether we can verify the bz first and use a separate bz to track it? or
> > > > other suggestion?
> > > 
> > > Please open another BZ for comment 9.
> > > 
> > > This changes and BZ was for NetKVM only.
> > 
> > actually remove rng device can also detect this issue, So its a regression
> > issue related to "iommu device + virtio netkvm device". update the following
> > details  to make it more clear:
> > 
> > 
> > 1. start guest with following qemu command line:
> > 
> >  /usr/libexec/qemu-kvm \
> >     -name 'avocado-vt-vm3' \
> >     -machine q35,kernel-irqchip=split  \
> >     -nodefaults \
> >     -vga std  \
> >     -device
> > pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,
> > addr=0x3 \
> >     -device
> > pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x3.0x1 \
> >     -device
> > pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x3.0x2 \
> >     -device
> > pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x3.0x3 \
> >     -device
> > pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x3.0x4 \
> >     -device
> > pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x3.0x5 \
> >     -device
> > pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x3.0x6 \
> >     -device
> > pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x3.0x7 \
> >    -device
> > virtio-scsi-pci,id=virtio_scsi_pci1,bus=pci.2,disable-legacy=on,disable-
> > modern=false,iommu_platform=on,ats=on  \
> >     -blockdev
> > driver=file,cache.direct=off,cache.no-flush=on,filename=/home/win2022-64-
> > virtio-scsi.qcow2,node-name=data_node \
> >     -blockdev driver=qcow2,node-name=data_disk,file=data_node \
> >     -device
> > scsi-hd,drive=data_disk,id=disk1,bus=virtio_scsi_pci1.0,serial=kk \
> >     -m 14336  \
> >     -smp 2,maxcpus=4 \
> >     -cpu
> > 'Skylake-Server',hv_stimer,hv_synic,hv_vpindex,hv_relaxed,
> > hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_frequencies,hv_runtime,hv_tlbflush,
> > hv_reenlightenment,hv_stimer_direct,hv_ipi,+kvm_pv_unhalt \
> >     -device piix3-usb-uhci,id=usb -device usb-tablet,id=input0 \
> >     -vnc :10  \
> >     -rtc base=localtime,clock=host,driftfix=slew  \
> >     -boot order=cdn,once=c,menu=off,strict=off \
> >     -enable-kvm \
> >     -qmp tcp:0:1231,server,nowait \
> >     -monitor stdio \
> >     -device intel-iommu,intremap=on,eim=on,device-iotlb=on \
> >     -device
> > virtio-net-pci,mac=9a:36:83:b6:3d:05,id=idJVpmsF,netdev=id23ZUK6,bus=pci.3,
> > disable-legacy=on,disable-modern=false,iommu_platform=on,ats=on  \
> >     -netdev tap,id=id23ZUK6,vhost=on \
> >     -drive
> > id=drive_cd1,if=none,snapshot=off,aio=threads,cache=none,media=cdrom,file=/
> > home/kvm_autotest_root/iso/windows/winutils.iso\
> >     -device ide-cd,id=cd2,drive=drive_cd1,bus=ide.0,unit=0 \
> > 
> > 
> > 2. connect to guest session: 
> > # nc -C $guest_ip 10022
> > 
> > 
> > Acutual result:
> > 
> > after step2, Return garbled
> > eg:
> > 
> > [root@dell-per730-47 ~]# nc -C 10.73.74.208 10022
> > Please wait...
> > `���Y�a���J0Afd�M����F���� �?����
> > 
> > 
> > 
> > C:\>ipconfig
> > 
> > Windows IP Configuration
> > 
> > /�����������'��������������M������E
> > C:\>
> > 
> > 
> > 
> > Additional info:
> > 
> > 1.try the same steps above with 210 driver, no return garbled
> > 2. just remove  -device intel-iommu,intremap=on,eim=on,device-iotlb=on , can
> > not hit this issue, the result like following, So it should be a regression
> > issue related to "iommu device + virtio netkvm device".
> > 
> > [root@dell-per730-47 ~]# nc -C 10.73.74.208 10022
> > Please wait...
> > Microsoft Windows [Version 10.0.20348.169]
> > (c) Microsoft Corporation. All rights reserved.
> > 
> > C:\>ipconfig
> > 
> > Windows IP Configuration
> > 
> > 
> > Ethernet adapter Ethernet Instance 0 2:
> > 
> >    Connection-specific DNS Suffix  . : lab.eng.pek2.redhat.com
> >    Link-local IPv6 Address . . . . . : fe80::20a4:b429:19d4:59aa%8
> >    IPv4 Address. . . . . . . . . . . : 10.73.74.208
> >    Subnet Mask . . . . . . . . . . . : 255.255.252.0
> >    Default Gateway . . . . . . . . . : 10.73.75.254
> 
> Can you please provide the service\application on the guest that opening
> 10022 port?

Checked the port 10022 and the corresponding pid,
Port 10022 used by rss.exe
The screenshot as follows:
https://docs.google.com/document/d/1CAvnSNDKMP0hg7W9SW-F0vgrSZXeIZkUDNxLKNqOCBw/edit?usp=sharing
Comment 20 Yvugenfi@redhat.com 2021-10-28 07:01:32 UTC 
Please set regression flag to this BZ.
The change brakes NetKVM with IOMMU by introducing random corruption to the packets.
Comment 22 leidwang@redhat.com 2021-11-04 02:03:05 UTC 
Hi Yan, 

Could you adjust the DTM? Since the DTM is too later, our test time will be very tight. We'd better change the DTM to 23 or earlier.

Thanks!
Comment 23 leidwang@redhat.com 2021-11-05 10:59:07 UTC 
Tested netkvm with build 214,there is no regression.Thanks!
Comment 29 jinl 2023-08-02 01:30:32 UTC 
*** Bug 2213484 has been marked as a duplicate of this bug. ***
Comment 30 RHEL Program Management 2023-08-14 07:27:43 UTC 
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.
Comment 31 RHEL Program Management 2023-08-15 07:27:36 UTC 
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues.
Note You need to log in before you can comment on or make changes to this bug.