From: Anthony Liguori <aliguori@us.ibm.com>
To: Rusty Russell <rusty@rustcorp.com.au>,
"Michael S. Tsirkin" <mst@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
Stefan Hajnoczi <stefanha@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
KONRAD Frederic <fred.konrad@greensocs.com>
Subject: Re: [PATCH RFC] virtio-pci: new config layout: using memory BAR
Date: Thu, 06 Jun 2013 09:59:48 -0500 [thread overview]
Message-ID: <874ndbp9nf.fsf@codemonkey.ws> (raw)
In-Reply-To: <87y5anrjlf.fsf@rustcorp.com.au>
Hi Rusty,
Rusty Russell <rusty@rustcorp.com.au> writes:
> Anthony Liguori <aliguori@us.ibm.com> writes:
>> 4) Do virtio-pcie, make it PCI-e friendly (drop the IO BAR completely), give
>> it a new device/vendor ID. Continue to use virtio-pci for existing
>> devices potentially adding virtio-{net,blk,...}-pcie variants for
>> people that care to use them.
>
> Now you have a different compatibility problem; how do you know the
> guest supports the new virtio-pcie net?
We don't care.
We would still use virtio-pci for existing devices. Only new devices
would use virtio-pcie.
> If you put a virtio-pci card behind a PCI-e bridge today, it's not
> compliant, but AFAICT it will Just Work. (Modulo the 16-dev limit).
I believe you can put it in legacy mode and then there isn't the 16-dev
limit. I believe the only advantage of putting it in native mode is
that then you can do native hotplug (as opposed to ACPI hotplug).
So sticking with virtio-pci seems reasonable to me.
> I've been assuming we'd avoid a "flag day" change; that devices would
> look like existing virtio-pci with capabilities indicating the new
> config layout.
I don't think that's feasible. Maybe 5 or 10 years from now, we switch
the default adapter to virtio-pcie.
>> I think 4 is the best path forward. It's better for users (guests
>> continue to work as they always have). There's less confusion about
>> enabling PCI-e support--you must ask for the virtio-pcie variant and you
>> must have a virtio-pcie driver. It's easy to explain.
>
> Removing both forward and backward compatibility is easy to explain, but
> I think it'll be harder to deploy. This is your area though, so perhaps
> I'm wrong.
My concern is that it's not real backwards compatibility.
>> It also maps to what regular hardware does. I highly doubt that there
>> are any real PCI cards that made the shift from PCI to PCI-e without
>> bumping at least a revision ID.
>
> Noone expected the new cards to Just Work with old OSes: a new machine
> meant a new OS and new drivers. Hardware vendors like that.
Yup.
> Since virtualization often involves legacy, our priorities might be
> different.
So realistically, I think if we introduce virtio-pcie with a different
vendor ID, it will be adopted fairly quickly. The drivers will show up
in distros quickly and get backported.
New devices can be limited to supporting virtio-pcie and we'll certainly
provide a way to use old devices with virtio-pcie too. But for
practical reasons, I think we have to continue using virtio-pci by
default.
Regards,
Anthony Liguori
>
> Cheers,
> 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
next prev parent reply other threads:[~2013-06-06 14:59 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-28 16:03 [PATCH RFC] virtio-pci: new config layout: using memory BAR Michael S. Tsirkin
2013-05-28 17:15 ` Anthony Liguori
[not found] ` <87bo7vvxej.fsf@codemonkey.ws>
2013-05-28 17:32 ` Michael S. Tsirkin
2013-05-28 17:43 ` Paolo Bonzini
2013-05-29 2:02 ` Laszlo Ersek
2013-05-29 4:33 ` Rusty Russell
[not found] ` <87mwremmm8.fsf@rustcorp.com.au>
2013-05-29 7:27 ` Paolo Bonzini
2013-05-29 8:05 ` Michael S. Tsirkin
2013-05-29 10:07 ` Laszlo Ersek
2013-05-28 18:53 ` Anthony Liguori
2013-05-28 19:27 ` Michael S. Tsirkin
2013-05-29 4:31 ` Rusty Russell
2013-05-29 8:24 ` Michael S. Tsirkin
2013-05-29 8:52 ` Paolo Bonzini
2013-05-29 9:00 ` Peter Maydell
2013-05-29 10:08 ` Michael S. Tsirkin
2013-05-29 10:53 ` Peter Maydell
2013-05-29 12:16 ` Michael S. Tsirkin
2013-05-29 12:28 ` Paolo Bonzini
2013-05-29 12:37 ` Michael S. Tsirkin
2013-05-29 12:52 ` Anthony Liguori
2013-05-29 13:24 ` Michael S. Tsirkin
2013-05-29 13:35 ` Peter Maydell
2013-05-29 13:41 ` Paolo Bonzini
2013-05-29 14:02 ` Michael S. Tsirkin
2013-05-29 14:18 ` Anthony Liguori
2013-05-30 7:43 ` Michael S. Tsirkin
2013-05-29 14:16 ` Anthony Liguori
[not found] ` <8761y1q3aw.fsf@codemonkey.ws>
2013-05-29 14:30 ` Michael S. Tsirkin
2013-05-29 14:32 ` Paolo Bonzini
2013-05-29 14:52 ` Michael S. Tsirkin
2013-05-29 14:55 ` Anthony Liguori
[not found] ` <87k3mhkf7o.fsf@codemonkey.ws>
2013-05-29 16:12 ` Michael S. Tsirkin
2013-05-29 18:16 ` Michael S. Tsirkin
2013-05-30 3:58 ` Rusty Russell
2013-05-30 5:55 ` Michael S. Tsirkin
2013-05-30 7:55 ` Michael S. Tsirkin
2013-06-03 0:17 ` Rusty Russell
2013-05-30 13:53 ` Anthony Liguori
2013-05-30 14:01 ` Michael S. Tsirkin
2013-06-03 0:26 ` Rusty Russell
2013-06-03 10:11 ` Michael S. Tsirkin
2013-06-04 5:31 ` Rusty Russell
2013-06-04 6:42 ` Michael S. Tsirkin
2013-06-05 7:19 ` Rusty Russell
2013-06-05 10:22 ` Michael S. Tsirkin
2013-06-05 12:59 ` Anthony Liguori
2013-06-05 14:09 ` Michael S. Tsirkin
2013-06-05 15:08 ` Anthony Liguori
2013-06-05 15:19 ` Michael S. Tsirkin
2013-06-05 15:46 ` Anthony Liguori
[not found] ` <87bo7ktvaw.fsf@codemonkey.ws>
2013-06-05 16:20 ` Michael S. Tsirkin
2013-06-05 18:57 ` Anthony Liguori
2013-06-05 19:43 ` Michael S. Tsirkin
2013-06-05 19:52 ` Michael S. Tsirkin
2013-06-05 20:45 ` Anthony Liguori
2013-06-05 21:15 ` H. Peter Anvin
2013-06-05 21:15 ` Michael S. Tsirkin
2013-06-05 20:42 ` Anthony Liguori
2013-06-05 21:14 ` Michael S. Tsirkin
2013-06-05 21:53 ` Anthony Liguori
[not found] ` <87d2s0mdh8.fsf@codemonkey.ws>
2013-06-05 22:19 ` Benjamin Herrenschmidt
2013-06-05 22:53 ` Anthony Liguori
2013-06-05 23:27 ` Benjamin Herrenschmidt
2013-06-05 19:54 ` Michael S. Tsirkin
2013-06-06 3:42 ` Rusty Russell
2013-06-06 14:59 ` Anthony Liguori [this message]
2013-06-07 1:58 ` Rusty Russell
2013-06-07 8:25 ` Peter Maydell
2013-06-05 21:10 ` H. Peter Anvin
2013-06-05 21:17 ` Michael S. Tsirkin
2013-06-05 21:50 ` Anthony Liguori
2013-06-05 21:55 ` H. Peter Anvin
2013-06-05 22:08 ` Anthony Liguori
2013-06-05 23:07 ` H. Peter Anvin
2013-06-06 0:41 ` Anthony Liguori
2013-06-06 6:34 ` Gleb Natapov
2013-06-06 13:53 ` H. Peter Anvin
2013-06-06 15:02 ` Anthony Liguori
2013-06-06 15:06 ` Gerd Hoffmann
2013-06-06 15:10 ` Gleb Natapov
2013-06-06 15:19 ` H. Peter Anvin
2013-06-06 15:22 ` Gerd Hoffmann
2013-07-08 4:25 ` Kevin O'Connor
[not found] ` <871u8fp9jd.fsf@codemonkey.ws>
2013-06-07 11:30 ` Gleb Natapov
2013-06-11 7:10 ` Michael S. Tsirkin
2013-06-11 7:53 ` Gleb Natapov
2013-06-11 8:02 ` Michael S. Tsirkin
2013-06-11 8:03 ` Gleb Natapov
2013-06-11 8:19 ` Michael S. Tsirkin
2013-06-11 8:22 ` Gleb Natapov
2013-06-11 8:30 ` Michael S. Tsirkin
2013-06-11 8:32 ` Gleb Natapov
2013-06-11 8:04 ` Michael S. Tsirkin
2013-06-06 8:02 ` Michael S. Tsirkin
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=874ndbp9nf.fsf@codemonkey.ws \
--to=aliguori@us.ibm.com \
--cc=fred.konrad@greensocs.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=rusty@rustcorp.com.au \
--cc=stefanha@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).