Hi, > Understood, but I'd really prefer a file in docs/. We should be > rigorous about having formal specs for all of our paravirtual devices. > The code shouldn't be the spec.
Well, pci-serial and pci-bridge are *not* paravirtual devices. They follow a specification describing the programming interface, and likewise does real hardware. Same is true for all usb host controllers and ahci btw. I can certainly place a text file for pci-serial in docs/spec/, but there isn't much qemu-specific to specify ... Guests have generic drivers which just match the PCI class and programming interface fields in the pci config space and don't care (much) what the pci id is. The pci id is used to print the name of the hardware, apply quirks, handle vendor-specific extensions, and in case of pci-serial windows also uses it to figure whenever the device is just a serial port or a modem (behind a 16550). Whenever we'll pick the pci ids of existing hardware or assign a unique one is a matter of taste. Picking unique IDs from Red Hat vendor space doesn't make the devices paravirtual. usb controllers and ahci got IDs matching the ones of the intel chipsets (piix, q35) emulated by qemu, which makes sense in that case. For pci-serial windows needs a "driver" (which is just a inf file, the driver itself is shipped by windows). So in that case it is easier to go with our own ids I think, as we can simply ship a inf file then. When picking the IDs of other cards, existing as real hardware, users would have to hunt down the (non-redistributable) driver package for the real hardware to get it going in windows. cheers, Gerd
