From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 A848521A13487 for ; Thu, 4 May 2017 08:19:38 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0F6AD7F40B; Thu, 4 May 2017 15:19:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0F6AD7F40B Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 0F6AD7F40B Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-98.phx2.redhat.com [10.3.116.98]) by smtp.corp.redhat.com (Postfix) with ESMTP id 99A1F7D94A; Thu, 4 May 2017 15:19:34 +0000 (UTC) To: Igor Mammedov , Gerd Hoffmann References: <1382eb04-9646-133b-9ce5-8293cb54745f@redhat.com> <1493794647.8581.144.camel@redhat.com> <159c4eae-4e13-7958-59f4-dfab4c1bf16e@redhat.com> <1493819062.8581.177.camel@redhat.com> <64591d6f-b5d9-d73d-26a5-4c157b9bd541@redhat.com> <20170504102359.45724558@nial.brq.redhat.com> <20170504160058.2e162b01@nial.brq.redhat.com> <1493908860.371.34.camel@redhat.com> <20170504165008.16012308@nial.brq.redhat.com> Cc: "Kinney, Michael D" , Paolo Bonzini , edk2-devel-01 , "Yao, Jiewen" , "Fan, Jeff" From: Laszlo Ersek Message-ID: <72ed3a64-9c61-2096-d131-fbef6d176984@redhat.com> Date: Thu, 4 May 2017 17:19:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170504165008.16012308@nial.brq.redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 04 May 2017 15:19:38 +0000 (UTC) Subject: Re: SMRAM sizes on large hosts X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 15:19:38 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 05/04/17 16:50, Igor Mammedov wrote: > On Thu, 04 May 2017 16:41:00 +0200 > Gerd Hoffmann wrote: > >> Hi, >> >>> There is another thing to consider here, when vm is migrated to newer >>> qemu(with newer firmware version) then it might not boot on the next >>> restart due to hitting old set limit. >> >> Firmware is part of the migration data, so you have the same version on >> both ends. > true, until VM is shut down. After that it loads new firmware > from target host. So user will have see error that tells what is wrong > and manually fix limit value if vm startup config to another value > that would work for this specific fw/config combo. I've been generally promoting the idea that firmware logs should be captured by libvirt by default, and exposed to the user similarly to QEMU error messages / error logs... Some rate limiting and/or log rotation would be necessary, so that guest code cannot flood the host system with infinite logs, but that wouldn't prevent saving error messages from non-malicious firmware. Laszlo