All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Using PCI config space to indicate config location
Date: Wed, 10 Oct 2012 15:41:57 +0200	[thread overview]
Message-ID: <20121010134157.GA7922@redhat.com> (raw)
In-Reply-To: <87vceiih4j.fsf@codemonkey.ws>

On Wed, Oct 10, 2012 at 08:36:12AM -0500, Anthony Liguori wrote:
> Rusty Russell <rusty@rustcorp.com.au> writes:
> 
> > Gerd Hoffmann <kraxel@redhat.com> 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?
> 
> I still think it's a bad idea to rely on something so "new" in something
> as fundamental as virtio-pci unless we have to.
> 
> Regards,
> 
> Anthony Liguori

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.

> >
> > So let's return to that proposal, giving something like this:
> >
> > /* IDs for different capabilities.  Must all exist. */
> > /* FIXME: Do we win from separating ISR, NOTIFY and COMMON? */
> > /* Common configuration */
> > #define VIRTIO_PCI_CAP_COMMON_CFG	1
> > /* Notifications */
> > #define VIRTIO_PCI_CAP_NOTIFY_CFG	2
> > /* ISR access */
> > #define VIRTIO_PCI_CAP_ISR_CFG		3
> > /* Device specific confiuration */
> > #define VIRTIO_PCI_CAP_DEVICE_CFG	4
> >
> > /* This is the PCI capability header: */
> > struct virtio_pci_cap {
> > 	u8 cap_vndr;	/* Generic PCI field: PCI_CAP_ID_VNDR */
> > 	u8 cap_next;	/* Generic PCI field: next ptr. */
> > 	u8 cap_len;	/* Generic PCI field: sizeof(struct virtio_pci_cap). */
> > 	u8 cfg_type;	/* One of the VIRTIO_PCI_CAP_*_CFG. */
> > 	u8 bar;		/* Where to find it. */
> > 	u8 unused;
> > 	__le16 offset;	/* Offset within bar. */
> > 	__le32 length;	/* Length. */
> > };
> >
> > This means qemu can point the isr_cfg into the legacy area if it wants.
> > In fact, it can put everything in BAR0 if it wants.
> >
> > Thoughts?
> > 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

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	virtualization@lists.linux-foundation.org,
	Gerd Hoffmann <kraxel@redhat.com>,
	kvm@vger.kernel.org, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Using PCI config space to indicate config location
Date: Wed, 10 Oct 2012 15:41:57 +0200	[thread overview]
Message-ID: <20121010134157.GA7922@redhat.com> (raw)
In-Reply-To: <87vceiih4j.fsf@codemonkey.ws>

On Wed, Oct 10, 2012 at 08:36:12AM -0500, Anthony Liguori wrote:
> Rusty Russell <rusty@rustcorp.com.au> writes:
> 
> > Gerd Hoffmann <kraxel@redhat.com> 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?
> 
> I still think it's a bad idea to rely on something so "new" in something
> as fundamental as virtio-pci unless we have to.
> 
> Regards,
> 
> Anthony Liguori

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.

> >
> > So let's return to that proposal, giving something like this:
> >
> > /* IDs for different capabilities.  Must all exist. */
> > /* FIXME: Do we win from separating ISR, NOTIFY and COMMON? */
> > /* Common configuration */
> > #define VIRTIO_PCI_CAP_COMMON_CFG	1
> > /* Notifications */
> > #define VIRTIO_PCI_CAP_NOTIFY_CFG	2
> > /* ISR access */
> > #define VIRTIO_PCI_CAP_ISR_CFG		3
> > /* Device specific confiuration */
> > #define VIRTIO_PCI_CAP_DEVICE_CFG	4
> >
> > /* This is the PCI capability header: */
> > struct virtio_pci_cap {
> > 	u8 cap_vndr;	/* Generic PCI field: PCI_CAP_ID_VNDR */
> > 	u8 cap_next;	/* Generic PCI field: next ptr. */
> > 	u8 cap_len;	/* Generic PCI field: sizeof(struct virtio_pci_cap). */
> > 	u8 cfg_type;	/* One of the VIRTIO_PCI_CAP_*_CFG. */
> > 	u8 bar;		/* Where to find it. */
> > 	u8 unused;
> > 	__le16 offset;	/* Offset within bar. */
> > 	__le32 length;	/* Length. */
> > };
> >
> > This means qemu can point the isr_cfg into the legacy area if it wants.
> > In fact, it can put everything in BAR0 if it wants.
> >
> > Thoughts?
> > 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

  reply	other threads:[~2012-10-10 13:41 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-27  0:29 Proposal for virtio standardization Rusty Russell
2012-09-27  0:29 ` [Qemu-devel] " Rusty Russell
2012-09-27  0:29 ` Rusty Russell
2012-10-04 18:49 ` [Qemu-devel] " Anthony Liguori
2012-10-04 18:49   ` Anthony Liguori
2012-10-08  2:21   ` Using PCI config space to indicate config location Rusty Russell
2012-10-08  2:21     ` [Qemu-devel] " Rusty Russell
2012-10-08 13:58     ` Anthony Liguori
2012-10-08 13:58       ` Anthony Liguori
2012-10-08 14:58       ` Gerd Hoffmann
2012-10-08 14:58         ` Gerd Hoffmann
2012-10-08 15:09         ` Anthony Liguori
2012-10-08 15:09           ` Anthony Liguori
2012-10-08 20:13           ` Gerd Hoffmann
2012-10-08 20:13             ` Gerd Hoffmann
2012-10-08 20:55             ` Anthony Liguori
2012-10-08 20:55               ` Anthony Liguori
2012-10-08 23:56               ` Rusty Russell
2012-10-09  1:51                 ` Anthony Liguori
2012-10-09  3:16                   ` Rusty Russell
2012-10-09  3:16                   ` Rusty Russell
2012-10-09  3:16                     ` Rusty Russell
2012-10-09 10:17                     ` Avi Kivity
2012-10-09 10:17                       ` Avi Kivity
2012-10-09 14:03                       ` Anthony Liguori
2012-10-09 14:03                         ` Anthony Liguori
2012-10-09 13:56                     ` Anthony Liguori
2012-10-09 13:56                     ` Anthony Liguori
2012-10-09 13:56                       ` Anthony Liguori
2012-10-10  3:44                       ` Rusty Russell
2012-10-10  3:44                         ` Rusty Russell
2012-10-10 11:37                         ` Michael S. Tsirkin
2012-10-10 11:37                           ` Michael S. Tsirkin
2012-10-09 21:09                     ` Jamie Lokier
2012-10-09 21:09                       ` [Qemu-devel] " Jamie Lokier
2012-10-10  3:44                       ` Rusty Russell
2012-10-10  3:44                         ` Rusty Russell
2012-10-11  0:08                         ` Rusty Russell
2012-10-11  0:08                           ` Rusty Russell
2012-10-11  0:08                         ` Rusty Russell
2012-10-09 21:09                     ` Jamie Lokier
2012-10-09  6:33                   ` Gerd Hoffmann
2012-10-09  6:33                     ` Gerd Hoffmann
2012-10-09 15:26                     ` Anthony Liguori
2012-10-09 15:26                       ` Anthony Liguori
2012-10-09 20:24                       ` Gerd Hoffmann
2012-10-09 20:24                         ` Gerd Hoffmann
2012-10-10  2:54                         ` Rusty Russell
2012-10-10  2:54                         ` Rusty Russell
2012-10-10  2:54                           ` Rusty Russell
2012-10-10 13:36                           ` Anthony Liguori
2012-10-10 13:41                             ` Michael S. Tsirkin [this message]
2012-10-10 13:41                               ` Michael S. Tsirkin
2012-10-11  0:43                               ` Rusty Russell
2012-10-11  0:43                               ` Rusty Russell
2012-10-11  0:43                                 ` [Qemu-devel] " Rusty Russell
2012-10-09 15:26                     ` Anthony Liguori
2012-10-10  8:34                 ` Michael S. Tsirkin
2012-10-10  8:34                   ` Michael S. Tsirkin
2012-10-08 13:58     ` Anthony Liguori
2012-10-10  8:30     ` Michael S. Tsirkin
2012-10-10  8:30       ` [Qemu-devel] " Michael S. Tsirkin
2012-10-11  1:18       ` Rusty Russell
2012-10-11  1:18         ` [Qemu-devel] " Rusty Russell
2012-10-11 10:23         ` Michael S. Tsirkin
2012-10-11 10:23           ` [Qemu-devel] " Michael S. Tsirkin
2012-10-11 22:29           ` Rusty Russell
2012-10-11 22:29             ` [Qemu-devel] " Rusty Russell
2012-10-12  9:33             ` Michael S. Tsirkin
2012-10-12  9:33               ` [Qemu-devel] " Michael S. Tsirkin
2012-10-12  9:51               ` Rusty Russell
2012-10-12  9:51                 ` [Qemu-devel] " Rusty Russell
2012-10-12 10:02                 ` Michael S. Tsirkin
2012-10-12 10:02                   ` [Qemu-devel] " Michael S. Tsirkin
2012-10-16 13:15                   ` Rusty Russell
2012-10-16 13:15                   ` Rusty Russell
2012-10-16 13:15                     ` [Qemu-devel] " Rusty Russell
2012-10-16 13:30                     ` Michael S. Tsirkin
2012-10-16 13:30                       ` [Qemu-devel] " Michael S. Tsirkin
2012-10-16 13:52                       ` Rusty Russell
2012-10-16 13:52                         ` [Qemu-devel] " Rusty Russell
2012-10-16 13:52                       ` Rusty Russell
2012-10-11 22:29           ` Rusty Russell
2012-10-08  2:21   ` Rusty Russell
2012-10-04 18:49 ` [Qemu-devel] Proposal for virtio standardization Anthony Liguori
2012-10-09 14:02 ` Cornelia Huck
2012-10-09 14:02 ` Cornelia Huck
2012-10-09 14:02   ` [Qemu-devel] " Cornelia Huck
2012-10-10  3:46   ` Rusty Russell
2012-10-10  3:46     ` [Qemu-devel] " Rusty Russell
2012-10-10  3:46   ` Rusty Russell

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=20121010134157.GA7922@redhat.com \
    --to=mst@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=virtualization@lists.linux-foundation.org \
    /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.