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::243; helo=mail-it0-x243.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (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 5E9A921F6A6E1 for ; Sat, 24 Feb 2018 00:08:17 -0800 (PST) Received: by mail-it0-x243.google.com with SMTP id n7so5542448ita.5 for ; Sat, 24 Feb 2018 00:14:20 -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=HYQD97sce++sUWMzEAnk3kbRKMRe4TEXmbGRXbeWGTM=; b=b2Wl0sa/X/jl9VbLU9eptGz85xk1T77x8aRoZbMIEC1bPoWLdkJSrZXRQzM+lmuZQf aCnxpMRTMMs0v3wuA5kFWh/p2w4JVjv1gbdBOKrNKQybKIFhhdheT/nHqlnJsczWaH7G raXkmOYwyzPzivGa+QP9iPDwx8gc1wvSm2Ctw= 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=HYQD97sce++sUWMzEAnk3kbRKMRe4TEXmbGRXbeWGTM=; b=EtGcFm9cPcxHy8i3L7pKmW9TA1KO0iYVppoIjVujmt5TE9IDfzasbv1I4THRFb66pK i1R2+W+hB/s1aAdteQR4Acmj6xcQp4x8I4pivBlMpHZtifPn6ONJ/1RgiJpPeKeTmJEw Kn6+z1kh+C23Ocok2ZqtCBVhVQTZ8MA6OwH7Rkq9HTsuTez1DUhW8srTBY50MhW7igv6 w27fW21AawLhXwunF91foQ8LX1AvlRd7xkdaXbBbJGskQljvcLrZGi+z5iEImv+oHOlI 6FSm2y0/IQblX7XZGKR94qETWOZ7hWQUJl5yZXVO6gscEYfhns8IBc3UWXdmPH/IkUHi 0eRQ== X-Gm-Message-State: APf1xPDS5wvSEi+MI0nto+ujl/FZQi8g8pv128d3StkZT20IRjTRKEam cVWrpctecsilVYqKM5cNwZyOPh5BDs1eKKcm5BIQkQ== X-Google-Smtp-Source: AG47ELuCYpic7ALEGh5wo9Kz8Y7HyaTnkRat2WaAXZfx09GDDfn9gv3feTs9NVeZ8BW6VAriqCBwEgrAO/BcIjO/B5E= X-Received: by 10.36.13.5 with SMTP id 5mr5458959itx.68.1519460059676; Sat, 24 Feb 2018 00:14:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Sat, 24 Feb 2018 00:14:19 -0800 (PST) In-Reply-To: <56a50ebe-c27e-1a0b-1d96-30b0443fee59@Intel.com> References: <1519376008-110662-1-git-send-email-heyi.guo@linaro.org> <1519376008-110662-2-git-send-email-heyi.guo@linaro.org> <20180224015139.GB111587@SZX1000114654> <56a50ebe-c27e-1a0b-1d96-30b0443fee59@Intel.com> From: Ard Biesheuvel Date: Sat, 24 Feb 2018 08:14:19 +0000 Message-ID: To: "Ni, Ruiyu" Cc: Guo Heyi , Laszlo Ersek , "edk2-devel@lists.01.org" , Eric Dong , Michael D Kinney , Star Zeng Subject: Re: [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation 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: Sat, 24 Feb 2018 08:08:18 -0000 Content-Type: text/plain; charset="UTF-8" On 24 February 2018 at 03:11, Ni, Ruiyu wrote: ... >>> (6) For all of these, I believe that we have to think about the corner >>> case when the Translation value is not a multiple of (Alignment + 1). >>> >>> "Alignment" comes from the PCI BAR in question, whereas Base comes from >>> the platform PciHostBridgeLib. I think these are fairly independent (you >>> can plug a 3rd party, discrete PCI card into a board). I find it >>> plausible that the card has such a huge MMIO BAR (and alignment) that >>> the platform's Translation offset is not a multiple thereof. >>> >>> So, which "view" has to be aligned here? The PCI (device) view, or the >>> host (CPU) view? >> >> >> I believe the alignment requirement is from PCI view, not the CPU view. >> This >> also implies alignment in allocating GCD resources becomes meaningless. > > I agree. It's an issue we need to think about. > > All address spaces in GCD are added by gDS->AddXXX(). > So it means for a given range of address [HostBase, HostLimit) in GCD, > the corresponding device address is > [HostBase + Offset, HostLimit + Offset). > E.g.: GCD entry = [0xFFD, 0x3FFD), Offset = 0x3 > The corresponding device address range is [0x1000, 0x4000) > If we want to allocate 3 page-aligned pages of MMIO from GCD, > current AllocateResource() implementation will fail to allocate. > > What will the Offset be in real world? > If it's quite small (smaller than device required alignment), > thing becomes complicated. I even cannot think of any solution. > If it's quite large (larger than device required alignment), > thing becomes easy. Today's implementation can handle it well. > I see two typical use cases for this address translation feature: - adding an address offset to TypeTranslation I/O range, i.e., two RCs both using 0x0-0xffff on the PCI side, but requiring non-overlapping memory ranges on the CPU side (this is a limitation in the ACPI spec, where an I/O range cannot be subject to address translation and type translation at the same time) - mapping a MMIO32 range high in the CPU address space In both cases, I think it is reasonable as an implementation requirement that the translation is sufficiently aligned, maybe even to the size of the entire window.