From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bw6hk-00012a-Fz for qemu-devel@nongnu.org; Mon, 17 Oct 2016 08:07:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bw6hh-000061-BH for qemu-devel@nongnu.org; Mon, 17 Oct 2016 08:07:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55988) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bw6hh-00005d-6E for qemu-devel@nongnu.org; Mon, 17 Oct 2016 08:07:41 -0400 Message-ID: <1476706056.6417.11.camel@redhat.com> From: Gerd Hoffmann Date: Mon, 17 Oct 2016 14:07:36 +0200 In-Reply-To: <5880f354-9f1e-a9cf-9728-5ac5168ef9c9@redhat.com> References: <1476366759-29119-1-git-send-email-marcel@redhat.com> <38124233-a3e5-9073-262e-e7ef96676eea@redhat.com> <5880f354-9f1e-a9cf-9728-5ac5168ef9c9@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH V2 RESEND] docs: add PCIe devices placement guidelines List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: Marcel Apfelbaum , qemu-devel@nongnu.org, Peter Maydell , Andrew Jones , "Michael S. Tsirkin" , Andrea Bolognani , Alex Williamson , Laine Stump Hi, > {26} Another remark (important to me) in this section: the document > doesn't state firmware expectations. It's clear the firmware is expected > to reserve no IO space for PCI Express Downstream Ports and Root Ports, > but what about MMIO? >=20 > We discussed this at length with Alex, but I think we didn't conclude > anything. It would be nice if firmware received some instructions from > this document in this regard, even before we implement our own ports and > bridges in QEMU. Where do we stand in terms of generic pcie ports btw? I think the plan is still to communicate suggestions to the firmware via pci config space, either by using reset defaults of the limit register, or of that doesn't work due to initialization order issues using some vendor specific pcie capability. As long as we don't have that there is nothing do document, other than maybe briefly mentioning the plans we have and documenting the current state (2M mmio in seabios, and I think the same for ovmf). The patches adding the generic ports can also update the documentation of course. > >=20 > If we think such recommendations are out of scope at this point, *and* > noone disagrees strongly (Gerd?), then I could add some experimental > fw_cfg knobs to OVMF for this, such as (units in MB): Why? Given that the virtio mmio bar size issue is solved I don't see a strong reason to hurry with this. Just wait until the generic ports are there. cheers, Gerd