From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <lersek@redhat.com>
Received-SPF: Pass (sender SPF authorized) identity=mailfrom;
 client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com;
 receiver=edk2-devel@lists.01.org 
Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by ml01.01.org (Postfix) with ESMTPS id 43F8021E25690
 for <edk2-devel@lists.01.org>; Wed, 14 Mar 2018 03:23:53 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com
 [10.11.54.5])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mx1.redhat.com (Postfix) with ESMTPS id 8020DE44B5;
 Wed, 14 Mar 2018 10:30:15 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-44.rdu2.redhat.com
 [10.10.120.44])
 by smtp.corp.redhat.com (Postfix) with ESMTP id AE2B4AB58A;
 Wed, 14 Mar 2018 10:30:14 +0000 (UTC)
From: Laszlo Ersek <lersek@redhat.com>
To: edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>,
 Xiang Zheng <xiang.zheng@linaro.org>,
 Ard Biesheuvel <ard.biesheuvel@linaro.org>
References: <20180313212233.19215-1-lersek@redhat.com>
Message-ID: <3aa98cee-4836-4843-5c72-2608df307293@redhat.com>
Date: Wed, 14 Mar 2018 11:30:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180313212233.19215-1-lersek@redhat.com>
X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
 (mx1.redhat.com [10.11.55.1]); Wed, 14 Mar 2018 10:30:15 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]);
 Wed, 14 Mar 2018 10:30:15 +0000 (UTC) for IP:'10.11.54.5'
 DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com'
 HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:''
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  <edk2-devel.lists.01.org>
List-Unsubscribe: <https://lists.01.org/mailman/options/edk2-devel>,
 <mailto:edk2-devel-request@lists.01.org?subject=unsubscribe>
List-Archive: <http://lists.01.org/pipermail/edk2-devel/>
List-Post: <mailto:edk2-devel@lists.01.org>
List-Help: <mailto:edk2-devel-request@lists.01.org?subject=help>
List-Subscribe: <https://lists.01.org/mailman/listinfo/edk2-devel>,
 <mailto:edk2-devel-request@lists.01.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2018 10:23:54 -0000
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit

On 03/13/18 22: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.

Thanks everyone for the super quick feedback!

Commit range 12957e56d26d..ff1d0fbfbaec.

Cheers,
Laszlo