Re: [PATCH 0/4] Virtio non-discoverable devices

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

Hello Daniil,

Could you please use a text based email client? Gmail does not
consider the indentation as threading, so the context below is
unintelligible

On 8 March 2018 at 08:21, Daniil Egranov <daniil.egranov@arm.com> wrote:
> Hello Ard,
>
> Thanks for reply. Please see my comments below.
>
> On 03/07/2018 02:03 AM, Ard Biesheuvel wrote:
>
> (+ Laszlo)
>
> Hello Daniil,
>
> On 7 March 2018 at 01:36, Daniil Egranov <daniil.egranov@arm.com> wrote:
>
> This is an attempt to add MMIO Virtio devices into the
> non-discoverable device registration procedure and allow
> Virtio PCI drivers to recognize and program such devices
> correctly.
>
> Why? The purpose of the non-discoverable device layer is to make
> non-PCI controllers that can be driven by PCI class drivers appear as
> PCI devices. We have started using the base non-discoverable device
> protocol for other devices as well, but the PCI wrapper is really only
> intended for PCI class drivers.
>
>
> I am looking for a proper way to handle multiple MMIO Virtio devices on a
> single platform. As both PCI and MMIO types of Virtio device programmed in
> about the same way, non-discoverable devices approach was looking valid.
>
> I understand you point. Correct me if I am wrong but all non-discoverable
> devices are MMIO devices so if there is PCI version of the device exists,
> PCI wrapper can be used. The Virtio PCI class devices are using
> VirtioPciDeviceDxe driver. Is this driver not fitting to the category of PCI
> class drivers?
>

That is not the point. The Intel guys have decided that the AHCI, XHCI
and other drivers (whose specs do no mandate PCI) are implemented as
PCI drivers only, which means that they are essentially combining two
layers of the driver stack (the PCI part and the _HCI part)

Splitting all of those drivers into PCI drivers that produce _HCI
protocols and _HCI drivers that produce the USB host, SATA host, etc
protocols is not going to be accepted by upstream EDK2, so instead, we
decided to turn the PCI 'emulation' that was duplicated across many
platforms into a proper abstraction.

In the virtio case, we don't have that problem. We have MMIO and PCI
support using drivers that use the proper abstractions, and so
presenting MMIO devices as PCI devices is really a step backwards.

What are you trying to achieve that the current code won't let you?

-- 
Ard.