From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:400c:c0c::233; helo=mail-wr0-x233.google.com; envelope-from=roman.bacik@broadcom.com; receiver=edk2-devel@lists.01.org Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 A3B702063E318 for ; Thu, 3 May 2018 07:58:16 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id v5-v6so17955388wrf.9 for ; Thu, 03 May 2018 07:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=a5KObKepl6imBiSJ+okWdqTfnLxOA/GSqVARhbc/UeI=; b=eHaIux2JRECM7N0Yj/LsRvQd8FQ69noSWEHXIqdaI0H58qvS9oReo56Ayv0dwKrco3 20vTN9tPz0+JuwQkxYlCzGnbdc0FvaK8i9VnnxLPjc79k9a27PQ0jnGJJ8CVdMo375ev uqtcpBbPI4x7IFHvYHAaXpemmzjITHA71yDKA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=a5KObKepl6imBiSJ+okWdqTfnLxOA/GSqVARhbc/UeI=; b=Xl33QyuGpkDEDfqOHJdeONp2T7dTF8QU74CnqqB0C7w/wTI9RM0jjpMqzTyY+slko7 cYNrcFp+RfUvC1X949TuD7wiOl7nyuk4tIv6O1GpDex5MOTuTPjxonSJzSDGmKkocHB8 7sfqIpe3pmewC27YY5wHR8WlE/Qdi/+2y+Ewd0rmIfAKiyThUKV7RjhV7eCMn/zc2/0e /Z+HJqBM5BWYCrGvVlXTTUc+s4DzyMo5ZqQ2uR15SI0Stn2LZRQK/CU12vgUT2ThTrTx xUIjqjJ+pVHdD1gBcx5yeb29fgCLNt/bYznFoduaC0UA7D3UDunpE+ycw2c7/EiMaJir xKnA== X-Gm-Message-State: ALQs6tAV+MmYoVf7hinC0dqo27AeLjO6sZhMcRn2B1FHIiDeio09OdWR yfSW8dJyB2pc3X9xyPcyZx3MkB+bau7qQybkH7Qe0g== X-Google-Smtp-Source: AB8JxZpNZJOj4l+NBRIFK6fJXKNzy+Co+83/hmjj3rm0uaDxuhjjMWY2Me2OZT/GC/Qbn8G3CKhfc4tufo9ktbIxvfs= X-Received: by 2002:adf:9d8c:: with SMTP id p12-v6mr17909530wre.14.1525359494683; Thu, 03 May 2018 07:58:14 -0700 (PDT) From: Roman Bacik References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGKesxFKDyBnoQwMKioqNjIzx29aAFK0DnSpKaPgYA= Date: Thu, 3 May 2018 07:58:13 -0700 Message-ID: To: Laszlo Ersek Cc: edk2-devel@lists.01.org, Ruiyu Ni , Vladimir Olovyannikov Subject: Re: [PATCH v2] MdeModulePkg/Bus: Enable ascending resource list X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 14:58:17 -0000 Content-Type: text/plain; charset="UTF-8" Laszlo, Thank you very much for your explanation. > -----Original Message----- > From: Laszlo Ersek [mailto:lersek@redhat.com] > Sent: Thursday, May 3, 2018 6:52 AM > To: Roman Bacik > Cc: edk2-devel@lists.01.org; Ruiyu Ni; Vladimir Olovyannikov > Subject: Re: [edk2] [PATCH v2] MdeModulePkg/Bus: Enable ascending > resource list > > On 05/02/18 20:07, Roman Bacik wrote: > > Some processors require resource list sorted in ascending order. > > > > Cc: Ruiyu Ni > > Cc: Vladimir Olovyannikov > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Roman Bacik > > --- > > MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf | 1 + > > .../Bus/Pci/PciBusDxe/PciResourceSupport.c | 43 > ++++++++++++++++++---- > > MdeModulePkg/MdeModulePkg.dec | 3 ++ > > MdeModulePkg/MdeModulePkg.dsc | 1 + > > 4 files changed, 41 insertions(+), 7 deletions(-) > > I don't understand the goal of this patch. > > (Please don't take my comments as "review" or arguments against this > patch, > I'd just like to understand the issue.) > > To my understanding, InsertResourceNode() keeps PCI resources sorted in > descending *alignment* order -- because a larger power-of-two alignment is > also suitable for a smaller power-of-two alignment. > > Say, we have a bridge with two devices behind it. The first device has one > MMIO BAR of size 32MB (requiring the same 32MB natural alignment), while > the other device has one MMIO BAR, of size 4MB (requiring the same 4MB > natural alignment). > > Ordering the resources in descending *alignment* order means that we'll > 1st > allocate the 32MB BAR, at a suitably aligned address. The important thing > is > that the end of that allocation will *also* be aligned at 32MB, hence we > can > allocate, as 2nd step, the 4MB BAR right there. No gaps needed. > > If the 4MB BAR was allocated 1st (naturally aligned), then its end address > might not be naturally aligned for becoming the base address of the > remaining 32MB BAR. Thus we might have to waste some MMIO aperture to > align the large BAR correctly. > > Here's an example output from PciBusDxe running as part of OVMF: > > > PciBus: Resource Map for Root Bridge PciRoot(0x0) [...] > > Type = Mem32; Base = 0x80000000; Length = 0x8100000; > > Alignment = > 0x3FFFFFF > > Base = 0x80000000; Length = 0x4000000; Alignment = 0x3FFFFFF; > Owner = PCI [00|02|00:14] > > Base = 0x84000000; Length = 0x4000000; Alignment = 0x3FFFFFF; > Owner = PCI [00|02|00:10] > > Base = 0x88000000; Length = 0x2000; Alignment = 0x1FFF; > > Owner = > PCI [00|02|00:18] > > Base = 0x88002000; Length = 0x1000; Alignment = 0xFFF; > > Owner = > PCI [00|07|00:14] > > Base = 0x88003000; Length = 0x1000; Alignment = 0xFFF; > > Owner = > PCI [00|06|07:10] > > Base = 0x88004000; Length = 0x1000; Alignment = 0xFFF; > > Owner = > PCI [00|05|00:14] > > Base = 0x88005000; Length = 0x1000; Alignment = 0xFFF; > > Owner = > PCI [00|03|00:14] > > [...] > > The base addresses are already sorted in ascending order; what's > descending > is the alignment -- and that seems correct, because it conserves MMIO > aperture (no gaps needed). > > Can you please explain what's wrong with this approach for your platform, > and what the desired behavior is? > > Can you post a log snippet that shows a placement that's right for your > platform? We are also patching allocation order bottom up search starting at BaseAddress. This placement is desirable and working for us after applying the submitted two patches: PciBus: Resource Map for Bridge [00|00|00] Type = PMem32; Base = 0x60000000; Length = 0x100000; Alignment = 0xFFFFF Base = 0x60000000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [01|00|00:18]; Type = PMem64 Base = 0x60020000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [01|00|01:18]; Type = PMem64 Base = 0x60040000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [01|00|02:18]; Type = PMem64 Base = 0x60060000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [01|00|03:18]; Type = PMem64 Base = 0x60080000; Length = 0x10000; Alignment = 0xFFFF; Owner = PCI [01|00|00:10]; Type = PMem64 Base = 0x60090000; Length = 0x10000; Alignment = 0xFFFF; Owner = PCI [01|00|01:10]; Type = PMem64 Base = 0x600A0000; Length = 0x10000; Alignment = 0xFFFF; Owner = PCI [01|00|02:10]; Type = PMem64 Base = 0x600B0000; Length = 0x10000; Alignment = 0xFFFF; Owner = PCI [01|00|03:10]; Type = PMem64 Base = 0x600C0000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [01|00|00:20]; Type = PMem64 Base = 0x600C1000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [01|00|01:20]; Type = PMem64 Base = 0x600C2000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [01|00|02:20]; Type = PMem64 Base = 0x600C3000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [01|00|03:20]; Type = PMem64 > > Thanks, > Laszlo Thanks, Roman