qemu-devel
[Top][All Lists]
Advanced

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]