From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c06::22f; helo=mail-io0-x22f.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 899F4223DB100 for ; Mon, 12 Mar 2018 00:25:06 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id e30so10267284ioc.3 for ; Mon, 12 Mar 2018 00:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3oRsr4cP5MIx93cYxFmpEWseM1yMNaFPVuMEbHUxLxk=; b=jSuZsUMVmLc2miYrqkwVWEp2dwqKMDX++CsiMGpxFOGBtr/VS7fxutGNgjk82idqEv zJXtgzF3aKc+aI7DXdssYCIlTonj7dx6xhNScPWaCcv9jLDkseOQEhyOQxuj0TTER0cw Afw3gXVkszDYZSqAQfMPEnAujtQFc1ysHo7P8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3oRsr4cP5MIx93cYxFmpEWseM1yMNaFPVuMEbHUxLxk=; b=BAPoP6kDibT1RuM43tqO3JK/lwoPyO999lGZ54WOhbj6GaBlczLdPqcSIgRUZ5mkST 6vxoWB07WfTa+1HB1guuPDlxyReQflhyCxX6cPrhqOoLkkxViv7V3ZbewC1CE4xWCe0q 8+v/B2sfKVO3JkO8SKSJG+M78zuIUnK2dpzhElYq79485ZiC0obDnKKOXxOwzbNjO5cC SnUdq4hSQNUK6FN2CToiyopPEwClgb7j99QletvQT0aD+ndqsJyQupG0b2dUewD6ZT6y lQGeL8fyyvrjphEd1rh5SH2tOcvQkIfxQHeum2qq57ugEcgboCAZwF2F/tGqgyw81xy4 0RQg== X-Gm-Message-State: AElRT7HVBlfHxvsGri0AJDYJkRH85rx/ua2LcdTbS+ZI4TwHOY0H5aVf zb1qD8L5kbWw97BsNQbTo0enkXwFxwpMJiIuneqkPA== X-Google-Smtp-Source: AG47ELvBUeV3jNTGAZ1MWheYVkgF6IChqNcqKnbqcWBWOq5yzgWX4QWZeyjoxfRDUW7ObSvcedi9DUo3wqJjhw30cSE= X-Received: by 10.107.41.16 with SMTP id p16mr7711889iop.173.1520839885983; Mon, 12 Mar 2018 00:31:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Mon, 12 Mar 2018 00:31:25 -0700 (PDT) In-Reply-To: References: <20180307013637.16462-1-daniil.egranov@arm.com> From: Ard Biesheuvel Date: Mon, 12 Mar 2018 07:31:25 +0000 Message-ID: To: Daniil Egranov Cc: "edk2-devel@lists.01.org" , Laszlo Ersek , Leif Lindholm Subject: Re: [PATCH 0/4] Virtio non-discoverable devices X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 07:25:07 -0000 Content-Type: text/plain; charset="UTF-8" On 12 March 2018 at 06:19, Daniil Egranov 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 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 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? >