From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web10.18937.1673425613727856627 for ; Wed, 11 Jan 2023 00:26:53 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=RWrQR0dK; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673425612; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9PuhLrqnpnyyggHMp4HdgjhdVGilgqkNNRiq7v8q+cs=; b=RWrQR0dKg5i3/sA9bEBwepjz3Nz0TxJmQlAJItCCKqDQd05iF+GXQmJhfNUmuO9EloABhb 3fpPU323+daZ7GEgNHhKGTy58bQLmbVqwvH9sCUazj5/7ilNstEysAF9jf6oA9zk6JoPYt hS6oI4/XEc7lHmrcjd5j0VkrgRzS/PU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-591-tqLfHoPhPBK31UFyADDnCg-1; Wed, 11 Jan 2023 03:26:49 -0500 X-MC-Unique: tqLfHoPhPBK31UFyADDnCg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6B0C8830DDD; Wed, 11 Jan 2023 08:26:49 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.238]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 256E2140EBF4; Wed, 11 Jan 2023 08:26:49 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id A263D180060E; Wed, 11 Jan 2023 09:26:47 +0100 (CET) Date: Wed, 11 Jan 2023 09:26:47 +0100 From: "Gerd Hoffmann" To: Laszlo Ersek Cc: devel@edk2.groups.io, Pawel Polawski , Jiewen Yao , Oliver Steffen , Jordan Justen , Ard Biesheuvel Subject: Re: [PATCH v2 4/4] OvmfPkg/PlatformInitLib: Add PlatformReservationConflictCB Message-ID: <20230111082647.d3bg3er5ofjpszuc@sirius.home.kraxel.org> References: <20230110082123.159521-1-kraxel@redhat.com> <20230110082123.159521-5-kraxel@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > > +/** > > + Check whenever the 64bit PCI MMIO window overlaps with a reservation > > + from qemu. If so move down the MMIO window to resolve the conflict. > > + > > + This happens on (virtal) AMD machines with 1TB address space, > > + because the AMD IOMMU uses an address window just below 1GB. > > (3) Same two typos, I think, as in the commit message. Duplicated by the power of cut + paste. > > + NewBase = (PlatformInfoHob->PcdPciMmio64Base - > > + PlatformInfoHob->PcdPciMmio64Size); > > (6) This appears a typo; we'll want > > NewBase + PcdPciMmio64Size == E820Entry->BaseAddr But then NewBase is not aligned. The assignment above moves it down while maintaining the existing alignment. > (9) Do we need any other checks or maybe assertions that we're only > conflicting with a reserved area, and/or that the subtraction for > NewBase does not underflow? > > I don't think we can "armor" this very well, I'm just pondering if there > are any egregious misunderstandings between QEMU and the firmware that > we might want to catch here. If not, that's OK of course. Yes, it's hard to design something which can handle all reservations qemu might do in the future correctly. And, yes, the code above works because we know the qemu reservation is smaller than the mmio window, so moving down to the next naturally aligned address actually solves the conflict. take care, Gerd