>> I 'd be happy with a simple comment explaining the 0x103f (e.g., >> /* Not yet using the full 0x1000 - 0x10ef to hedge our bets in case we >> broke the ABI.*/ >> as explained above) > > Thanks, I like your patch. > > Where did this idea of "experimental" range come from, BTW? In the qemu sources, there is a file pci-ids.txt that documents the PCI ID rules. I 'm attaching it for your convenience. > I prefer your module cmdline approach, as it discourages > deployment with such numbers. Great, I like this way better too, because it allows using the full experimental range (16 IDs) while also allowing for breaking the virtio_pci ABI. Thanks, Pantelis
PCI IDs for qemu ================ Red Hat, Inc. donates a part of its device ID range to qemu, to be used for virtual devices. The vendor ID is 1af4 (formerly Qumranet ID). The 1000 -> 10ff device ID range is used for VirtIO devices. The 1100 device ID is used as PCI Subsystem ID for existing hardware devices emulated by qemu. All other device IDs are reserved. VirtIO Device IDs ----------------- 1af4:1000 network device 1af4:1001 block device 1af4:1002 balloon device 1af4:1003 console device 1af4:1004 Reserved. to Contact Gerd Hoffmann <kraxel@xxxxxxxxxx> to get a 1af4:10ef device ID assigned for your new virtio device. 1af4:10f0 Available for experimental usage without registration. Must get to official ID when the code leaves the test lab (i.e. when seeking 1af4:10ff upstream merge or shipping a distro/product) to avoid conflicts.
