All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Pantelis Koukousoulas <pktoss@gmail.com>
Cc: kvm@vger.kernel.org, Rusty Russell <rusty@rustcorp.com.au>,
	Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [PATCH] Assign the correct pci id range to virtio_pci
Date: Sun, 26 Apr 2009 15:49:16 +0300	[thread overview]
Message-ID: <49F4584C.6000504@redhat.com> (raw)
In-Reply-To: <1295ed070904260544m25d781b1ueaeb3ba058818491@mail.gmail.com>

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.
>   


-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2009-04-26 12:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-24 11:17 [PATCH] Assign the correct pci id range to virtio_pci Pantelis Koukousoulas
2009-04-24 13:19 ` Anthony Liguori
     [not found]   ` <49F55DD1.8020506@redhat.com>
2009-04-27  8:39     ` Pantelis Koukousoulas
2009-04-27  9:01       ` Gerd Hoffmann
2009-04-27  9:11         ` Pantelis Koukousoulas
2009-04-27  9:16           ` Gerd Hoffmann
2009-04-27  9:24             ` Avi Kivity
2009-04-27 11:45               ` Pantelis Koukousoulas
2009-04-27 11:56                 ` Avi Kivity
2009-04-28 14:42                   ` Pantelis Koukousoulas
2009-04-28 15:19                     ` Gerd Hoffmann
2009-04-29  7:47                       ` Pantelis Koukousoulas
2009-04-26 10:36 ` Avi Kivity
2009-04-26 12:44   ` Pantelis Koukousoulas
2009-04-26 12:49     ` Avi Kivity [this message]
2009-04-26 23:49       ` Rusty Russell
2009-04-27  0:44         ` Anthony Liguori
2009-04-27  3:23           ` Pantelis Koukousoulas
2009-05-04  1:53             ` Rusty Russell
2009-05-04  2:32               ` Pantelis Koukousoulas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49F4584C.6000504@redhat.com \
    --to=avi@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=kvm@vger.kernel.org \
    --cc=pktoss@gmail.com \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.