[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH V2] hw/virtio-pci: fix virtio behaviour on moder
From: |
Cornelia Huck |
Subject: |
Re: [Qemu-devel] [PATCH V2] hw/virtio-pci: fix virtio behaviour on modern (PCIe) machines |
Date: |
Wed, 20 Jul 2016 13:23:03 +0200 |
On Wed, 20 Jul 2016 12:37:44 +0300
Marcel Apfelbaum <address@hidden> wrote:
> On 07/20/2016 12:16 PM, Cornelia Huck wrote:
> > On Tue, 19 Jul 2016 21:42:58 +0300
> > Marcel Apfelbaum <address@hidden> 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)
Thanks for the explanation!
>
> 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.
OK, sounds sensible. The transport-agnostic virtio-1 code should be
pretty sane at this point.