"Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: > On Wed, Oct 10, 2012 at 08:36:12AM -0500, Anthony Liguori wrote: >> Rusty Russell <rusty@xxxxxxxxxxxxxxx> writes: >> >> > Gerd Hoffmann <kraxel@xxxxxxxxxx> writes: >> >> So how about this: >> >> >> >> (1) Add a vendor specific pci capability for new-style virtio. >> >> Specifies the pci bar used for new-style virtio registers. >> >> Guests can use it to figure whenever new-style virtio is >> >> supported and to map the correct bar (which will probably >> >> be bar 1 in most cases). >> > >> > This was closer to the original proposal[1], which I really liked (you >> > can layout bars however you want). Anthony thought that vendor >> > capabilities were a PCI-e feature, but it seems they're blessed in PCI >> > 2.3. >> >> 2.3 was standardized in 2002. Are we confident that vendor extensions >> play nice with pre-2.3 OSes like Win2k, WinXP, etc? 2.2 (1998) had the capability IDs linked list, indicated by bit 4 in the status register, but reserved ids 7 and above. ID 9 (vendor specific) was added in 2.3; it should be ignored, but will require testing of course, like any change. 2.1 didn't have the capability ID linked list at all; bit 4 in the status register was reserved. QEMU's pci.c has capability support, and sets the capabiliy status bit and list pointer when the driver requests (eg. the eepro100). > Pre 2.3 it was the case that *all* space outside > the capability linked list, and any capability not > recognized by space, was considered vendor specific. > So there's no problem really. Oh in theory, sure. In practice, almost certainly. But this needs to be proved with actual testing. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
