public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Daniil Egranov <daniil.egranov@arm.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	Laszlo Ersek <lersek@redhat.com>,
	Leif Lindholm <leif.lindholm@linaro.org>
Subject: Re: [PATCH 0/4] Virtio non-discoverable devices
Date: Mon, 12 Mar 2018 07:31:25 +0000	[thread overview]
Message-ID: <CAKv+Gu8WRWuM8E2vbuMbKuAtXssB4MBZ9ffJ5KCvhgD_+T1R6g@mail.gmail.com> (raw)
In-Reply-To: <d5be9057-20e6-1f68-9f85-99a3edb5958a@arm.com>

On 12 March 2018 at 06:19, Daniil Egranov <daniil.egranov@arm.com> wrote:
> 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.
>

Thanks.

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

Well, that is only true because you are using
NonDiscoverableDeviceRegistrationLib, which encapsulates those exact
same things.

> In case of multiple Virtio MMIO devices, what will be a proper way to handle
> them?
>


  reply	other threads:[~2018-03-12  7:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-07  1:36 [PATCH 0/4] Virtio non-discoverable devices Daniil Egranov
2018-03-07  1:36 ` [PATCH 1/4] MdeModulePkg: Added new Virtio non-discoverable type and GUID Daniil Egranov
2018-03-07  1:36 ` [PATCH 2/4] NonDiscoverableDeviceRegistrationLib: Added Virtio support Daniil Egranov
2018-03-07  1:36 ` [PATCH 3/4] NonDiscoverablePciDeviceDxe: Added MMIO " Daniil Egranov
2018-03-07  1:36 ` [PATCH 4/4] VirtioPciDeviceDxe: Added non-discoverable " Daniil Egranov
2018-03-07  8:03 ` [PATCH 0/4] Virtio non-discoverable devices Ard Biesheuvel
2018-03-07 20:18   ` Laszlo Ersek
2018-03-08  8:21   ` Daniil Egranov
2018-03-08  8:29     ` Ard Biesheuvel
2018-03-12  6:19       ` Daniil Egranov
2018-03-12  7:31         ` Ard Biesheuvel [this message]
2018-03-07 10:56 ` Laszlo Ersek
2018-03-13  2:55   ` Daniil Egranov

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-list 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=CAKv+Gu8WRWuM8E2vbuMbKuAtXssB4MBZ9ffJ5KCvhgD_+T1R6g@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /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