Bug 1209730

Summary:	when boot a guest with a device the addr of which is invalid attached to pcie-switch, there is no error about valid addr value in monitor
Product:	Red Hat Enterprise Linux 7	Reporter:	Yanhui Ma <yama>
Component:	qemu-kvm-rhev	Assignee:	Marcel Apfelbaum <marcel>
Status:	CLOSED WONTFIX	QA Contact:	jingzhao <jinzhao>
Severity:	low	Docs Contact:
Priority:	low
Version:	7.2	CC:	ailan, chayang, hhuang, jinzhao, juzhang, laine, michen, virt-maint, xfu
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-04-26 13:21:00 UTC	Type:	Bug
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:
Bug Blocks:	1311684

Description Yanhui Ma 2015-04-08 05:25:40 UTC

Description of problem:

when boot a guest with a device(addr=0x,addr=a or addr=0x6) the addr of which is invalid attached to pcie-switch, guest can boot up successfully, there is no error about valid addr value in monitor, and there is no the attached device in guest.

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

kernel:
3.10.0-234.el7.x86_64
qemu-kvm:
qemu-kvm-rhev-2.2.0-8.el7.x86_64

How reproducible:

100%

Steps to Reproduce:
1.boot a guest with a device(addr=0x,addr=a or addr=0x6) the addr of which is invalid attached to pcie-switch

cmd:

/usr/libexec/qemu-kvm -machine q35,accel=kvm -name rhel7.2 -m 4G -cpu Opteron_G3,check -smp 4,sockets=4,cores=1,threads=1,maxcpus=4 \

-realtime mlock=on -numa node,cpus=0-1,mem=1024 -numa node,cpus=2,mem=1024 -numa node,cpus=3,mem=2048 \

-uuid 49a3438a-70a3-4ba8-92ce-3a05e0934608 -nodefaults -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,strict=on \

 -drive file=/home/RHEL-server-7.2-64.qcow2,if=none,id=drive-data-disk1,cache=writethrough,format=qcow2,aio=native,werror=stop,rerror=stop -device virtio-scsi-pci,id=scsi1,addr=0x13 -device scsi-hd,drive=drive-data-disk1,bus=scsi1.0,id=data-disk1,bootindex=0 \

-netdev tap,id=hostnet0,vhost=on,id=hostnet0,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=de:e0:7a:d2:b4:56,bus=pcie.0,addr=0x14 \

-monitor stdio -spice port=5000,password=redhat,seamless-migration=on,agent-mouse=off -usb -device usb-tablet,id=input0 \

-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=8,bus=pcie.0,addr=0x11 \

-device ioh3420,bus=pcie.0,id=root.0,slot=1 -device x3130-upstream,bus=root.0,id=upstream -device xio3130-downstream,bus=upstream,id=downstream0,chassis=1 -device nec-usb-xhci,id=hostusb,bus=downstream0,addr=a

2.
3.

Actual results:
Guest can boot up successfully, there is no error about valid addr value in monitor,and there is no nec-usb-xhci in guest.

Expected results:

There should be error about valid addr value in monitor and guest can not boot up successfully.
Additional info:

Comment 3 Marcel Apfelbaum 2016-03-01 10:06:30 UTC

Hi,

The correct way to deal with this is to implement "realize" all PCIe root ports.
A work has been started upstream:
https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg05167.html

Thanks,
Marcel

Comment 4 Laine Stump 2016-03-06 23:24:12 UTC

Since it hasn't been spelled out explicitly here, the error in configuration is that the nec-usb-xhci has been connected to an xio3130-downstream device with a slot/port# (addr) of "a", but the xio3130-downstream has only a single port, and its address is "0".

Just to avoid having this unnecessarily cloned into libvirt - the above situation could never happen in libvirt, because libvirt knows the min/max slot/port possibly for each type of PCI controller, and makes sure that those limits are honored (and since all supported qemu use in RHEL/RHEV is via libvirt, that means this situation would never be encountered in a RHEL/RHEV supported situation - a configuration error would be logged before it ever got to the point of starting qemu).