| Message ID | 1240571860-13832-1-git-send-email-pktoss@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Pantelis Koukousoulas wrote: > According to the file pci-ids.txt in qemu sources, the range of PCI > device IDs assigned to virtio_pci is 0x1000 to 0x10ff, with a few > subranges that have different rules regarding who can get an ID > there and how. > > Nevertheless, the full range should be assigned to the generic > virtio_pci driver, so that all corresponding devices, including > the experimental/unreleased ones "just work". > Gerd, since you appear to be managing the PCI ID range, what do you think? Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Pantelis Koukousoulas wrote: > According to the file pci-ids.txt in qemu sources, the range of PCI > device IDs assigned to virtio_pci is 0x1000 to 0x10ff, with a few > subranges that have different rules regarding who can get an ID > there and how. > > Nevertheless, the full range should be assigned to the generic > virtio_pci driver, so that all corresponding devices, including > the experimental/unreleased ones "just work". > Please copy the virtio maintainer (Rusty Russell <rusty@rustcorp.com.au>) on virtio guest patches.
> Please copy the virtio maintainer (Rusty Russell <rusty@rustcorp.com.au>) on > virtio guest patches. Well, for now the issue is whether my understanding of qemu/pci-ids.txt and the comment in virtio_pci.c that both say that the full 0x1000 - 0x10ff range of PCI device IDs is donated for virtio_pci devices is correct. If that is true, virtio_pci only claiming 0x1000 - 0x103f doesn't make much sense to me and looks more like a typo, because there is no explicit justification (perhaps in a comment) either. (3f does not even show up in pci-ids.txt). The ranges mentioned there are: 1000 -> 10ef (one needs to contact Gerd to reserve an unallocated ID in that range) and 10f0 -> 10ff (available for experimental devices, a random ID in that range can be used during private development without asking anyone as long as you are not shipping anything using it) the range ef -> f0 (exclusive) is reserved. From the above, my understanding is that virtio_pci should definitely claim at least 00 -> ef and most likely it should claim f0->ff too. The only reason not to claim some IDs is to allow someone to have virtio PCI devices that do *not* use the virtio_pci infrastructure but why would we want that? The reason I asked here (I guess qemu-devel would be just as relevant or more, but it has more traffic) is because Anthony is the author of virtio_pci.c (at least it looks like it) so hopefully he knows if that 3f was a typo or not and Gerd is responsible for the PCI ID namespace management so he knows if pci-ids.txt is correct or not. Once this issue is clarified I 'm happy to resend the same or an improved version of the patch as appropriate. Thanks, Pantelis -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Pantelis Koukousoulas wrote: >> Please copy the virtio maintainer (Rusty Russell <rusty@rustcorp.com.au>) on >> virtio guest patches. >> > > Well, for now the issue is whether my understanding of qemu/pci-ids.txt and the > comment in virtio_pci.c that both say that the full 0x1000 - 0x10ff range of PCI > device IDs is donated for virtio_pci devices is correct. > 0x1000-0x10ff is correct. I don't know where the 0x103f came from. Rusty? > If that is true, virtio_pci only claiming 0x1000 - 0x103f doesn't make > much sense to me > and looks more like a typo, because there is no explicit justification > (perhaps in a comment) either. > (3f does not even show up in pci-ids.txt). > > The ranges mentioned there are: > > 1000 -> 10ef (one needs to contact Gerd to reserve an unallocated ID > in that range) > and > 10f0 -> 10ff (available for experimental devices, a random ID in that > range can be > used during private development without asking > anyone as long as > you are not shipping anything using it) > > the range ef -> f0 (exclusive) is reserved. > > From the above, my understanding is that virtio_pci should definitely > claim at least > 00 -> ef and most likely it should claim f0->ff too. The only reason > not to claim some > IDs is to allow someone to have virtio PCI devices that do *not* use > the virtio_pci > infrastructure but why would we want that? > We wouldn't. If it isn't a virtio-pci device, it should leech an ID from someone else. > The reason I asked here (I guess qemu-devel would be just as relevant or more, > but it has more traffic) is because Anthony is the author of > virtio_pci.c (at least it looks like it) > Added cc. > so hopefully he knows if that 3f was a typo or not and Gerd is responsible for > the PCI ID namespace management so he knows if pci-ids.txt is correct or not. > > Once this issue is clarified I 'm happy to resend the same or an > improved version > of the patch as appropriate. >
On Sun, 26 Apr 2009 10:19:16 pm Avi Kivity wrote: > Pantelis Koukousoulas wrote: > >> Please copy the virtio maintainer (Rusty Russell <rusty@rustcorp.com.au>) on > >> virtio guest patches. > >> > > > > Well, for now the issue is whether my understanding of qemu/pci-ids.txt and the > > comment in virtio_pci.c that both say that the full 0x1000 - 0x10ff range of PCI > > device IDs is donated for virtio_pci devices is correct. > > > > 0x1000-0x10ff is correct. I don't know where the 0x103f came from. Rusty? We decided to hedge our bets in case we broke the ABI. AFAICT there's no reason to claim the full range until we need it. Wake me when device #32 is used :) Rusty. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Rusty Russell wrote: > On Sun, 26 Apr 2009 10:19:16 pm Avi Kivity wrote: > >> Pantelis Koukousoulas wrote: >> >>>> Please copy the virtio maintainer (Rusty Russell <rusty@rustcorp.com.au>) on >>>> virtio guest patches. >>>> >>>> >>> Well, for now the issue is whether my understanding of qemu/pci-ids.txt and the >>> comment in virtio_pci.c that both say that the full 0x1000 - 0x10ff range of PCI >>> device IDs is donated for virtio_pci devices is correct. >>> >>> >> 0x1000-0x10ff is correct. I don't know where the 0x103f came from. Rusty? >> > > We decided to hedge our bets in case we broke the ABI. > > AFAICT there's no reason to claim the full range until we need it. Wake me > when device #32 is used :) > Would be good to at least include the "experiment range" in case people are making third-party virtio modules and want to play around without replacing virtio-{pci,*}. Regards, Anthony Liguori > Rusty. > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 27, 2009 at 3:44 AM, Anthony Liguori <anthony@codemonkey.ws> wrote: > Rusty Russell wrote: >> >> On Sun, 26 Apr 2009 10:19:16 pm Avi Kivity wrote: >>> >>> 0x1000-0x10ff is correct. Â I don't know where the 0x103f came from. >>> Â Rusty? >>> >> >> We decided to hedge our bets in case we broke the ABI. >> >> AFAICT there's no reason to claim the full range until we need it. Â Wake >> me >> when device #32 is used :) >> > > Would be good to at least include the "experiment range" in case people are > making third-party virtio modules and want to play around without replacing > virtio-{pci,*}. 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) plus including the experimental range as Anthony proposed. The reason I came across this was I was playing with such a simple "third party" module and after reading pci-ids.txt I decided to choose 0x10f5 for myself only to find out that virtio_pci (and therefore my driver too) would not load any more. Thanks, Pantelis -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/24/09 15:19, Anthony Liguori wrote: > Pantelis Koukousoulas wrote: >> According to the file pci-ids.txt in qemu sources, the range of PCI >> device IDs assigned to virtio_pci is 0x1000 to 0x10ff, with a few >> subranges that have different rules regarding who can get an ID >> there and how. >> >> Nevertheless, the full range should be assigned to the generic >> virtio_pci driver, so that all corresponding devices, including >> the experimental/unreleased ones "just work". > > Gerd, since you appear to be managing the PCI ID range, what do you think? I'd suggest to exclude the experimental range by default (enable via module parameter) to make clear it isn't for regular use. cheers Gerd -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> I'd suggest to exclude the experimental range by default (enable via module > parameter) to make clear it isn't for regular use. Module parameter on what? The module parameter parsing code is afaict provided by the end-driver (e.g., virtio-net) which only speaks virtio and has no idea there is an actual PCI device in the backend. Isn't it easier to just make it clear that a PCI id within the 0x1000-10ef range is a prerequisite for inclusion in mainline linux / qemu and leave it at that? Btw, including just a subset of the experimental range like e.g., 0x10f0-0x10f3 would be fine with me, if there is a desire to be compatible with the "allow for breaking the ABI" rationale for the 0x1000-0x103f range. Thanks, Pantelis -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/27/09 10:39, Pantelis Koukousoulas wrote: >> I'd suggest to exclude the experimental range by default (enable via module >> parameter) to make clear it isn't for regular use. > > Module parameter on what? virtio_pci.ko Then you'll do something like this ... echo "options virtio_pci experimental=1" >> /etc/modprobe.d/virtio.conf ... to enable the experimental IDs. > The module parameter parsing code is afaict > provided by the end-driver (e.g., virtio-net) which only speaks virtio and has > no idea there is an actual PCI device in the backend. virtio_pci is a separate module and can have parameters too. cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Module parameter on what? > > virtio_pci.ko > > Then you'll do something like this ... > > echo "options virtio_pci experimental=1" >> /etc/modprobe.d/virtio.conf > > ... to enable the experimental IDs. Ok, I can sure live with such an arrangement :) Should the entire 0x10f0-0x10ff range be enabled by this option or just a subset? (and if a subset, how large, 4 IDs, more ?) Thanks, Pantelis -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/27/09 11:11, Pantelis Koukousoulas wrote: >>> Module parameter on what? >> virtio_pci.ko >> >> Then you'll do something like this ... >> >> echo "options virtio_pci experimental=1">> /etc/modprobe.d/virtio.conf >> >> ... to enable the experimental IDs. > > Ok, I can sure live with such an arrangement :) > Should the entire 0x10f0-0x10ff range be enabled by this option or > just a subset? > (and if a subset, how large, 4 IDs, more ?) That roughly matches the number of non-experimental IDs (1/4 of the complete range), so 4 IDs looks good to me. cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Gerd Hoffmann wrote: > On 04/27/09 11:11, Pantelis Koukousoulas wrote: >>>> Module parameter on what? >>> virtio_pci.ko >>> >>> Then you'll do something like this ... >>> >>> echo "options virtio_pci experimental=1">> /etc/modprobe.d/virtio.conf >>> >>> ... to enable the experimental IDs. >> >> Ok, I can sure live with such an arrangement :) >> Should the entire 0x10f0-0x10ff range be enabled by this option or >> just a subset? >> (and if a subset, how large, 4 IDs, more ?) > > That roughly matches the number of non-experimental IDs (1/4 of the > complete range), so 4 IDs looks good to me. Or maybe modprobe virtio-pci claim=0x10f2 claim=0x10f7
> Or maybe > > Â modprobe virtio-pci claim=0x10f2 claim=0x10f7 How about claim=0x10f2,0x10f7 instead so that it can be implemented as a standard module array parameter? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Pantelis Koukousoulas wrote: >> Or maybe >> >> modprobe virtio-pci claim=0x10f2 claim=0x10f7 >> > > How about claim=0x10f2,0x10f7 instead so that it can be implemented as > a standard module array parameter? > Even better.
On Mon, 27 Apr 2009 12:53:25 pm Pantelis Koukousoulas wrote: > On Mon, Apr 27, 2009 at 3:44 AM, Anthony Liguori <anthony@codemonkey.ws> wrote: > > Would be good to at least include the "experiment range" in case people are > > making third-party virtio modules and want to play around without replacing > > virtio-{pci,*}. > > 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? I prefer your module cmdline approach, as it discourages deployment with such numbers. Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>> 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@redhat.com> 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.
diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index 330aacb..db3f3b5 100644 --- a/drivers/virtio/virtio_pci.c +++ b/drivers/virtio/virtio_pci.c @@ -325,8 +325,8 @@ static int __devinit virtio_pci_probe(struct pci_dev *pci_dev, struct virtio_pci_device *vp_dev; int err; - /* We only own devices >= 0x1000 and <= 0x103f: leave the rest. */ - if (pci_dev->device < 0x1000 || pci_dev->device > 0x103f) + /* We only own devices >= 0x1000 and <= 0x10ff: leave the rest. */ + if (pci_dev->device < 0x1000 || pci_dev->device > 0x10ff) return -ENODEV; if (pci_dev->revision != VIRTIO_PCI_ABI_VERSION) {