From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 CF31A21190733 for ; Thu, 15 Nov 2018 02:39:34 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3F2BE300DA36; Thu, 15 Nov 2018 10:39:34 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-130.rdu2.redhat.com [10.10.120.130]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8D8AA1A923; Thu, 15 Nov 2018 10:39:33 +0000 (UTC) To: A Z , edk2-devel@lists.01.org References: From: Laszlo Ersek Message-ID: <7243ddb2-fc84-0598-6713-da5cd8a8d9c5@redhat.com> Date: Thu, 15 Nov 2018 11:39:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Thu, 15 Nov 2018 10:39:34 +0000 (UTC) Subject: Re: [OVMF+VIFO+QEMU] Large VM RAM allocation = Long Boot Times X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 10:39:35 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 11/15/18 06:58, A Z wrote: > This is an issue that involves a combination of different software > packages, so my apologies in advance if this is the wrong list to post on. > > I'm experiencing terrible boot times when I assign a large amount of RAM to > a VM when used in combination with VIFO/PCI-passthrough. > > On a VM with a Nvidia GTX 970 + USB controller and 24GiB of RAM assigned, > the time to the TianoCore splash screen is ~5 minutes. It's then ~30 > seconds before Windows 10 begins to boot (spinning dots). During this time, > the QEMU CPU core threads are 100% busy. > > According to `perf`, the QMU CPU core threads are spending most of their > time waiting on a spinlock over kvm->mmu_lock that's created by > kvm_zap_gfn_range. > > I'm fairly certain that ~1 year ago (if not longer) the same configuration > didn't take this long to boot. I see you posted this to vfio-users as well -- that would have been my recommendation anyway. I'll follow up there briefly. Thanks Laszlo