It's a bit complicated. There are a bunch of different vendor IDs in use in the linux/qemu virtualization world. I'm trying to cover them all.

Vendor ID 1af4 (Red Hat)

This is the Red Hat vendor ID. The device ID range from 1af4:1000 to 1af4:10ff is reserved for virtio-pci devices. For virtio 1.0 (and newer) devices there is a fixed relationship between virtio device ID and PCI device ID (offset 0x1040). So allocating a virtio device ID is enough, that implicitly allocates a PCI device ID too.

Qemu uses 1af4:1100 as PCI Subsystem ID for most devices.

The ivshmem device uses 1af4:1110.

Example (virtio scsi controller): 

$ lspci -vnns3:
03:00.0 SCSI storage controller [0100]: Red Hat, Inc. \
		Virtio SCSI [1af4:1048] (rev 01)
	Subsystem: Red Hat, Inc. Device [1af4:1100]
	[ ... ]

Vendor ID 1b36 (Red Hat / Qumranet)

This was the Qumranet vendor ID, and with the Qumranet aquisition by Red Hat the PCI vendor ID moved to Red Hat too. The device ID range from 1b36:0001 to 1b36:00ff is reserved for qemu, for virtual devices which are not virtio.

Such devices can either be qemu specific (test device, rocker ethernet) or devices which guest drivers typically match by PCI class code (pci bridges, serial, sdhci, xhci, nvme, ...) so they don't need to masquerade as some existing physical device.

New PCI ID assignments for qemu should use this pool.

Current allocations are listed in docs/specs/pci-ids.txt (here is the qemu 4.2 version) and have a #define in include/hw/pci/pci.h. If needed an addtional file in docs/specs/ should have the device specification.

To allocate an ID send a patch updating both docs/specs/pci-ids.txt and include/hw/pci/pci.h to the qemu-devel mailing list. Add me to Cc: to make sure it gets my attention. The commit message should describe the device you want allocate an ID for.

The 1b36:0100 ID is used by the qxl display device.

Example (xhci usb controller): 

$ lspci -vnns2:
02:00.0 USB controller [0c03]: Red Hat, Inc. QEMU XHCI Host \
		Controller [1b36:000d] (rev 01) (prog-if 30 [XHCI])
	Subsystem: Red Hat, Inc. Device [1af4:1100]
	[ ... ]

Vendor ID 1234

Even though there are #defines for PCI_VENDOR_ID_QEMU with this ID at various places this is not assigned to qemu. According to the PCI ID database this belongs to "Technical Corp".

Do not use this for new devices.

The qemu stdvga uses 1234:1111. This ID is hardcoded all over the place in guest drivers, so unfortunaly we are stuck with it.

Luckily no problems due to conflicts showed up so far, seems this vendor ID isn't used by the owner to build PCI devices.

Other Vendor IDs

It is perfectly fine to use IDs from other vendors for virtual qemu devices. They must be explicitly reserved for qemu though, to avoid possible conflicts with physical hardware from the same vendor. So, if you have your own vendor ID and want contribute a device to qemu you can also allocate an device ID from your ID space instead of taking one from the Red Hat 1b36 pool.

PCI IDs for emulated devices

When emulating existing physical hardware qemu will of course use the PCI IDs of the hardware being emulated, so the guest drivers will find the device. In most cases the PCI Subsystem ID 1af4:1100 indicates the device is emulated by qemu.

Example (sound device): 

$ lspci -vnns1b
00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) \
		HD Audio Controller [8086:293e] (rev 03)
	Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
	[ ... ]