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::22b; helo=mail-it0-x22b.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 1B87522135D3E for ; Wed, 14 Mar 2018 01:54:41 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id e64-v6so3732085ita.5 for ; Wed, 14 Mar 2018 02:01:04 -0700 (PDT) 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=lDoQDLG7lLmdAG4JVq7m/5QkXvt3xuSV5aKjM46zKqU=; b=GpXDgaBRBvuzwrZLL16gcAhusuGYDU85xz/IdNDIAdgFGP977lYh+ut5tLnDY1b6Hr j3SRc/IYzJGuPODA6YFUbukAXweIjEtF5AvDEHcswKOXrPl5QA84X6u4xH10Dg5bp81y rpsuiI90VKrG0swyQIAVC/7yNLKkDCiOuR81o= 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=lDoQDLG7lLmdAG4JVq7m/5QkXvt3xuSV5aKjM46zKqU=; b=ISMTnyLd+vmdLphkKfGXzXeQ0qqFgQwOitcwSz4X1uR9lVW21+NLQTXbZLezsWl3Xa HWMIdJ3hTsSC2E19SKOTyTLVlgjUQFQ10eaV157OzdKcL9APff4nLctBzrHF8sLOHjEj HYxEsATerp+ejCPboI4khuAj81oL//iTI+l6HvORziI71ZTXxcHr4+sMNepx8aAcVCYD GUoBDAz1cnlZUy7fwk5Q7AfpFir1iMyPgfAc8fmra+Ebff764x2WeDsG3KKy/g0q49Oy Y54vN/Ja4vuwBRv4Da/06XD3wJwHREuzSeCTtbwU1S/rQcj4p7EQ7JW02AEaHJ2OmiqQ 1kgw== X-Gm-Message-State: AElRT7EUrOfkUksKbQP7CHzb51JiGh+9lRj4WVLJ+eN8t+G/PSOifwK6 J8tmB96xdZ8fevs7ylR+nvG42xFgTbrEJ4Dt0E2o/A== X-Google-Smtp-Source: AG47ELudm1p2emS0cc+SSnEr9AhXdOCafSOZys1Gmwxv18kBZtGk4+8T5yesp+c31p3cs9/ySEDdxJH2shk7aj3sTF8= X-Received: by 10.36.145.199 with SMTP id i190mr1140574ite.50.1521018063436; Wed, 14 Mar 2018 02:01:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Wed, 14 Mar 2018 02:01:02 -0700 (PDT) In-Reply-To: <20180313212233.19215-1-lersek@redhat.com> References: <20180313212233.19215-1-lersek@redhat.com> From: Ard Biesheuvel Date: Wed, 14 Mar 2018 09:01:02 +0000 Message-ID: To: Laszlo Ersek Cc: edk2-devel-01 , Jordan Justen , Shannon Zhao , Xiang Zheng Subject: Re: [PATCH 0/6] OvmfPkg, ArmVirtQemu: leaner platform BDS policy for connecting devices 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: Wed, 14 Mar 2018 08:54:42 -0000 Content-Type: text/plain; charset="UTF-8" On 13 March 2018 at 21:22, Laszlo Ersek wrote: > Repo: https://github.com/lersek/edk2.git > Branch: qemu_bootorder_connect > > Adding tens or hundreds of bootable devices to a QEMU VM config slows > the OVMF and ArmVirtQemu boots to a crawl, several people have reported > in the past. > > There are at least two reasons for this (high pflash traffic due to > heavy nvvar massaging per device, and PCI config space access slowing > down on QEMU as the number of regions increases). However, part of the > pain is self-inflicted in our PlatformBootManagerLib instances: we > connect all bootable devices (for maximum compatibility with the user's > VM config) even if the user doesn't intend to boot off most of them. > > It's oft repeated that the set of devices connected during boot is > platform policy, so this series replaces the culprit > EfiBootManagerConnectAll() calls with a bit smarter algorithm. > > I sought to keep the commit messages under control. > This is really nice. Most platforms I've worked with just connect everything all the time, which is sloppy. I'm glad you fixed this for *VMF Tested-by: Ard Biesheuvel # ArmVirtQemu Reviewed-by: Ard Biesheuvel