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:c0b::236; helo=mail-it0-x236.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 CA21A224DCA37 for ; Thu, 8 Mar 2018 00:23:35 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id n128so18863790ith.1 for ; Thu, 08 Mar 2018 00:29:51 -0800 (PST) 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=qQWXZuQkH3ACgG4tmTmcmsrQj7v49c39xiQHRGEG4pY=; b=Wj7B7IlTaOQZ0bcWZIFsMQt/oUY18nRhAfiZ8+2lWGbGYzKiWzIPjF14b/gPzpqG5A IpYB4I4D6WI+cE0984gmsd0rtsW2/0WkfOquh8AdB7ZMmwtxRHjMMGMXKblEqCwYt8G/ HfSQAKHoOX9iEPv3/pcerpdKoSGdFV4ODzrbk= 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=qQWXZuQkH3ACgG4tmTmcmsrQj7v49c39xiQHRGEG4pY=; b=ZN8snQRnFaWR31/LCPM1Ocy3rcFOLLzT4oDGGFmQ18A0X7mhOdgnUZIm4Crjlz+bHY dRfAylq/t0025AdakaHgQutn46xjii5yq+HcQ4tMkNb1IjTnphF0UsQ3n0t79JB9ksHf +Y0K/UtWbZct3UmLzvHpEoocizJLeiQYDWQ9OyjT6s52Jxto4B/oSEHHKBhyrYpRn1Vr ddR+hpon6HPOg9uD38EDurH/c8usZtMqZU2ZxZASUBbRtKkFgzDY7RPsxvaJLvYk16kI SSh5ZuN4VCjHg8iPZooXXLTDKtqby6Jd2htpFFgCMo8JOs82/5G7E7GpuuQKtuISC2Hv Fy9Q== X-Gm-Message-State: AElRT7F+k4GRQq/L0hbpLTtWknorZKvaT/Xkl7ApfYdeeWDaIwOZIEXF 5p+InjTjaVTyE9r+2xw4kqVQ02tcdZ7Vd7pRyVIWwY5H X-Google-Smtp-Source: AG47ELuhoB8emv3DoSY/J8xyBzKcCAgqSekYgEdacpqAEhS4biOSoG+NEl+MfFLRZRXpPbfRhbv/RXStgvV+Pxz4ONw= X-Received: by 10.36.90.5 with SMTP id v5mr27172983ita.138.1520497790664; Thu, 08 Mar 2018 00:29:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Thu, 8 Mar 2018 00:29:49 -0800 (PST) In-Reply-To: References: <20180307013637.16462-1-daniil.egranov@arm.com> From: Ard Biesheuvel Date: Thu, 8 Mar 2018 08:29:49 +0000 Message-ID: To: Daniil Egranov Cc: Laszlo Ersek , "edk2-devel@lists.01.org" , 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: Thu, 08 Mar 2018 08:23:36 -0000 Content-Type: text/plain; charset="UTF-8" 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 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. What are you trying to achieve that the current code won't let you? -- Ard.