From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9278DC433DB for ; Mon, 11 Jan 2021 09:27:41 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 48802224F9 for ; Mon, 11 Jan 2021 09:27:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 48802224F9 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.64717.114366 (Exim 4.92) (envelope-from ) id 1kytU5-0001Mg-5p; Mon, 11 Jan 2021 09:27:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 64717.114366; Mon, 11 Jan 2021 09:27:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kytU5-0001MZ-2M; Mon, 11 Jan 2021 09:27:33 +0000 Received: by outflank-mailman (input) for mailman id 64717; Mon, 11 Jan 2021 09:27:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kytU4-0001MS-93 for xen-devel@lists.xenproject.org; Mon, 11 Jan 2021 09:27:32 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c3dff549-bf93-4627-80b8-4a96bcf61afa; Mon, 11 Jan 2021 09:27:30 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id E7143AD26; Mon, 11 Jan 2021 09:27:29 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c3dff549-bf93-4627-80b8-4a96bcf61afa X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1610357250; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C8QbALRVsgiAbV6fDH+A846dYGzwTGWKztkynP0oJBs=; b=tuZiSPPFdWPuEjlhUXGsyywhOCA/pkNKSr3dtzin61yutOP1WT2/jCR2G9WemDTw1h10nm tvNKu7gAdP3EltD4xGQcLRDK/GHhJZGAs1Yn+lLG2TDiAbnO23jjTV4vBAY4MU6eXXjcax N6V/EEIsv5OozhsV9UPFzCIs9DY/24s= Subject: Re: [PATCH] hvmloader: pass PCI MMIO layout to OVMF as an info table To: Igor Druzhinin Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org, iwj@xenproject.org, anthony.perard@citrix.com, xen-devel@lists.xenproject.org References: <1610340812-24397-1-git-send-email-igor.druzhinin@citrix.com> From: Jan Beulich Message-ID: Date: Mon, 11 Jan 2021 10:27:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <1610340812-24397-1-git-send-email-igor.druzhinin@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 11.01.2021 05:53, Igor Druzhinin wrote: > We faced a problem with passing through a PCI device with 64GB BAR to > UEFI guest. The BAR is expectedly programmed into 64-bit PCI aperture at > 64G address which pushes physical address space to 37 bits. OVMF uses > address width early in PEI phase to make DXE identity pages covering > the whole addressable space so it needs to know the last address it needs > to cover but at the same time not overdo the mappings. > > As there is seemingly no other way to pass or get this information in > OVMF at this early phase (ACPI is not yet available, PCI is not yet enumerated, > xenstore is not yet initialized) - extend the info structure with a new > table. Since the structure was initially created to be extendable - > the change is backward compatible. How does UEFI handle the same situation on baremetal? I'd guess it is in even more trouble there, as it couldn't even read addresses from BARs, but would first need to assign them (or at least calculate their intended positions). > --- a/tools/firmware/hvmloader/ovmf.c > +++ b/tools/firmware/hvmloader/ovmf.c > @@ -61,6 +61,14 @@ struct ovmf_info { > uint32_t e820_nr; > } __attribute__ ((packed)); > > +#define OVMF_INFO_PCI_TABLE 0 > +struct ovmf_pci_info { > + uint64_t low_start; > + uint64_t low_end; > + uint64_t hi_start; > + uint64_t hi_end; > +} __attribute__ ((packed)); Forming part of ABI, I believe this belongs in a public header, which consumers could at least in principle use verbatim if they wanted to. > @@ -74,9 +82,21 @@ static void ovmf_setup_bios_info(void) > static void ovmf_finish_bios_info(void) > { > struct ovmf_info *info = (void *)OVMF_INFO_PHYSICAL_ADDRESS; > + struct ovmf_pci_info *pci_info; > + uint64_t *tables = scratch_alloc(sizeof(uint64_t)*OVMF_INFO_MAX_TABLES, 0); I wasn't able to locate OVMF_INFO_MAX_TABLES in either xen/include/public/ or tools/firmware/. Where does it get defined? Also (nit) missing blanks around * . > uint32_t i; > uint8_t checksum; > > + pci_info = scratch_alloc(sizeof(struct ovmf_pci_info), 0); Is "scratch" correct here and above? I guess intended usage / scope will want spelling out somewhere. > + pci_info->low_start = pci_mem_start; > + pci_info->low_end = pci_mem_end; > + pci_info->hi_start = pci_hi_mem_start; > + pci_info->hi_end = pci_hi_mem_end; > + > + tables[OVMF_INFO_PCI_TABLE] = (uint32_t)pci_info; > + info->tables = (uint32_t)tables; > + info->tables_nr = 1; In how far is this problem (and hence solution / workaround) OVMF specific? IOW don't we need a more generic approach here? Jan