From: Marcel Apfelbaum <marcel@redhat.com>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: qemu-devel@nongnu.org, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH V2] hw/virtio-pci: fix virtio behaviour on modern (PCIe) machines
Date: Wed, 20 Jul 2016 12:37:44 +0300 [thread overview]
Message-ID: <578F4668.4050402@redhat.com> (raw)
In-Reply-To: <20160720111604.1573d0b7.cornelia.huck@de.ibm.com>
On 07/20/2016 12:16 PM, Cornelia Huck wrote:
> On Tue, 19 Jul 2016 21:42:58 +0300
> Marcel Apfelbaum <marcel@redhat.com> wrote:
>
>> Modern machines are expected to be used by newer setups with
>> modern guests aiming the use of the latest features.
>>
>> Enable modern and disable legacy for virtio devices
>> plugged into PCIe ports (Root ports or Downstream ports).
>> Using the Virtio 1 mode will remove the limitation
>> of the number of devices that can be attached to a machine
>> by removing the need for the IO BAR.
>
Hi Cornelia,
> Stupid question: Does this limitation show up for legacy and
> transitional, but not for modern?
>
Yes, with PCIe we need to disable the IO Bars.
Here is a short explanation:
The root cause it the PCIe architecture being "point to point" rather than 'shared bus'.
Each PCIe port supports only one device (multiple functions though) but is exposed
as a PCI bridge. The firmware will assign a 4k IO window for each bridge if
a device with IO BARs is attached to it.
So the firmware will allocate a 4K IO range for each PCIe port -> for each device.
Since the IO space is pretty limited we can support around 15 devices with IO BARs
attached to PCIe ports.
There are other ways to deal with the limitation like tweaking the firmware
to assign a smaller IO window (no PCI compliant, but it should work)
Looking only at the virtio scope, disabling legacy and enabling modern
should be enough.
> Would it make sense then to default to modern for PCIe and transitional
> for non-PCIe?
>
Yes. this patch only does the first part (deals only with the PCIe limitation),
but the next version will also include 'transitional' virtio as default for non PCIe slots.
Thanks,
Marcel
> (The term "virtio-1" mode always confuses me a bit; this may be because
> ccw unlike pci does not have modern-only devices - and even if we had,
> basically the only difference would be that we'd disallow devices
> without the VERSION_1 feature.)
>
next prev parent reply other threads:[~2016-07-20 9:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-19 18:42 [Qemu-devel] [PATCH V2] hw/virtio-pci: fix virtio behaviour on modern (PCIe) machines Marcel Apfelbaum
2016-07-19 22:56 ` Michael S. Tsirkin
2016-07-20 8:27 ` Marcel Apfelbaum
2016-07-20 8:41 ` Gerd Hoffmann
2016-07-20 9:01 ` Marcel Apfelbaum
2016-07-20 9:43 ` Gerd Hoffmann
2016-07-20 9:16 ` Cornelia Huck
2016-07-20 9:37 ` Marcel Apfelbaum [this message]
2016-07-20 11:23 ` Cornelia Huck
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=578F4668.4050402@redhat.com \
--to=marcel@redhat.com \
--cc=cornelia.huck@de.ibm.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.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).