From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHMiA-0002HG-S8 for qemu-devel@nongnu.org; Sun, 26 Jun 2016 22:55:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHMi5-0008OK-VN for qemu-devel@nongnu.org; Sun, 26 Jun 2016 22:55:46 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:2718) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHMi5-0008No-Hi for qemu-devel@nongnu.org; Sun, 26 Jun 2016 22:55:41 -0400 References: <1466151257-96318-1-git-send-email-chao.p.peng@linux.intel.com> <20160620060129.GE21465@pengc-linux.bj.intel.com> <76b78e27-c14f-ebb5-baab-a0bf75a60a10@redhat.com> <20160623083238.GI21465@pengc-linux.bj.intel.com> <3ce886ab-d1f5-aff4-82bc-398f05f502a7@redhat.com> <576CD5B1.2010100@huawei.com> <576CD61C.9030802@huawei.com> <92efd563-e5aa-ed71-d3ec-2a11ca2fc982@redhat.com> From: Claudio Fontana Message-ID: <57709586.1010004@huawei.com> Date: Mon, 27 Jun 2016 10:55:02 +0800 MIME-Version: 1.0 In-Reply-To: <92efd563-e5aa-ed71-d3ec-2a11ca2fc982@redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/9] Introduce light weight PC platform pc-lite List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Chao Peng Cc: Haozhong Zhang , Xiao Guangrong , Eduardo Habkost , "Michael S. Tsirkin" , qemu-devel@nongnu.org, anthony.xu@intel.com, gor Mammedov , Richard Henderson Hi Paolo, On 24.06.2016 14:53, Paolo Bonzini wrote: > > > On 24/06/2016 08:41, Claudio Fontana wrote: >>> I use qboot for similar goals, you mention that PAM is necessary because of how qboot probes parallel flash, >>> however in my custom platform I removed PAM completely from QEMU, and everything seems to work without any problems.. >> >> Btw before you ask: yes I am booting with pflash. > > By default low memory points to PCI address space > > 00000000000f0000-00000000000fffff (prio 1, RW): alias pam-ram @pc.ram 00000000000f0000-00000000000fffff [disabled] > 00000000000f0000-00000000000fffff (prio 1, RW): alias pam-pci @pc.ram 00000000000f0000-00000000000fffff [disabled] > 00000000000f0000-00000000000fffff (prio 1, R-): alias pam-rom @pc.ram 00000000000f0000-00000000000fffff [disabled] > 00000000000f0000-00000000000fffff (prio 1, RW): alias pam-pci @pci 00000000000f0000-00000000000fffff > > All that qboot does is enabling pam-ram: > > // Make ram from 0xc0000-0xf0000 read-write > int i; > for (i=0; i<6; i++) { > int pam = pambase + 1 + i; > pci_config_writeb(bdf, pam, 0x33); > } > > // Make ram from 0xf0000-0x100000 read-write and shadow BIOS > // We're still running from 0xffff0000 > pci_config_writeb(bdf, pambase, 0x30); > memcpy(low_start, bios_start, 0x10000); > > So if you remove PAM but you are leaving 0xC000-0x10000 pointing to > RAM, you are effectively moving qboot's PAM configuration to QEMU. :) > > Of these writes, only the last write is strictly necessary. qboot > currently uses 0xe0000-0xf0000 for the ACPI tables but we could move > them to the EBDA instead and save the initial loop. But I'd like to > see a trace saying how much time is spent configuring PAM exactly. > > Paolo > In my case the boot times are satisfactory including the PAM configuration loop in qboot. The reason I removed the PAM backend in QEMU (or rather, made them configurable via existing CONFIG_PAM), is as part of memory saving patches, not because of boottime issues. Ciao, Claudio