Hello Ard,
On 03/08/2018 02:29 AM, Ard Biesheuvel wrote:
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
I forced Thunderbird to plain text. I assumed it should follow a
previous email composition style. At least i did not have problem with
it so far. I hope it's formated correctly now.
On 8 March 2018 at 08:21, Daniil Egranov <daniil.egra...@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.egra...@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.
I see, thanks for details.
What are you trying to achieve that the current code won't let you?
I have a situation when a platform has multiple Virtio MMIO devices. The
initial way to handle them was installing a device path protocol and
calling VirtioMmioDeviceLib for each device as part of the platform DXE
driver. The non-discoverable way was hiding all these operations and was
looking like more clean approach.
In case of multiple Virtio MMIO devices, what will be a proper way to
handle them?
Thanks,
Daniil
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
