From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 1886C81EB6 for ; Wed, 16 Nov 2016 03:43:06 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id c20so204759886itb.0 for ; Wed, 16 Nov 2016 03:43:11 -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=kvx1iUTOcq2DxsnkxEPuaMQMMbK00Rnhlb4+vwEFoKo=; b=fYLkH1LlFCMFfQNtimTIBJ/XF3GtE8lyXss3G/zU7ECbJa0FMgeLmGEhkXoFsIosh5 mDmFk923kK3HQDLCejV9vi91cPI9Fz8eGEubpS4D8oUHSMjN2Imv6SWB4gamSs2gNqDv gKh5PoxEWfrBU56skEzJvKt1lsC4g/H8REOZs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kvx1iUTOcq2DxsnkxEPuaMQMMbK00Rnhlb4+vwEFoKo=; b=WupcUf3Rtk3YSpTWzVlEOY8sElHfplHcBy8WjbV1CGk6aIjcB29tgNBs1cUZzbk3lq Uwhhz3RYeoVfFDKl6QgN860SxqxoUzdA4kWKiQ8PDu0Kwi3xykFYg0ZSSyddrt1NyBLk H8wph6ejdUqFSxanoVt4bFBj883quapxCesZmsv6vos0G1TLbTXn+q6lNmlQfyJR4xC9 UU3p4dwM6yed8KEOr+r968XrYUsEhvuYH7j5VM/iUrrVcEbt4HO/nJ/UTvEfwxYZixBr c7zCBQdczO4ANmbmguef7usEiE3ACcmhRlvGzQdUKnp0w2HYAzUsB6apKJYev8ZSbLLu Tbdw== X-Gm-Message-State: ABUngvdDx4zylWlxJPpoKB6QgzdLq6RvcZ5ef2rjjmOEbqz5JmJEF5GKo0PPlWjjbstPemDZhzeSUA6lTA4X0h+J X-Received: by 10.107.2.8 with SMTP id 8mr2041368ioc.83.1479296590529; Wed, 16 Nov 2016 03:43:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.59.147 with HTTP; Wed, 16 Nov 2016 03:43:10 -0800 (PST) In-Reply-To: References: <1478173302-22349-1-git-send-email-ard.biesheuvel@linaro.org> <1478173302-22349-3-git-send-email-ard.biesheuvel@linaro.org> <734D49CCEBEEF84792F5B80ED585239D58E785B8@SHSMSX104.ccr.corp.intel.com> From: Ard Biesheuvel Date: Wed, 16 Nov 2016 11:43:10 +0000 Message-ID: To: "Ni, Ruiyu" Cc: "edk2-devel@lists.01.org" , "leif.lindholm@linaro.org" , "Kinney, Michael D" , "afish@apple.com" , "Tian, Feng" , "Zeng, Star" Subject: Re: [PATCH v2 3/5] MdeModulePkg: implement generic PCI I/O driver for non-discoverable devices X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 11:43:06 -0000 Content-Type: text/plain; charset=UTF-8 On 15 November 2016 at 11:30, Ard Biesheuvel wrote: > On 15 November 2016 at 08:40, Ni, Ruiyu wrote: >> Ard, >> Can you check whether PciLib can be used to replace the implementation in >> NonDiscoverablePciDeviceIo.c? >> > > OK I am not sure how this should work. This driver needs to coexist with real PCI host bridge drivers, and the config space access method is fully defined by the requirements of the driver, i.e., each PCI config space access should be served from the fake PCI config space in memory, and never be forwarded to a real device. So /providing/ a PciLib implementation, and requiring that that particular implementation must be used with this driver makes no sense, I think. And depending on a PciLib implementation does not make sense either, since the platform cannot choose which method to use. Note that we are not emulating a PCI bus hierarchy, where a single contiguous chunk of memory emulates the entire config space of several devices. Each device is fully independent, and provides a minimal config space to describe the type of device, and the BARs Or did I miss something?