Re: [Qemu-devel] [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address

From: Laszlo Ersek <lersek@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>, qemu-devel@nongnu.org
Cc: yingwen.chen@intel.com, devel@edk2.groups.io,
	phillip.goerl@oracle.com, alex.williamson@redhat.com,
	jiewen.yao@intel.com, jun.nakajima@intel.com,
	michael.d.kinney@intel.com, pbonzini@redhat.com,
	boris.ostrovsky@oracle.com, rfc@edk2.groups.io,
	joao.m.martins@oracle.com
Subject: Re: [Qemu-devel] [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address
Date: Mon, 9 Sep 2019 21:20:45 +0200	[thread overview]
Message-ID: <aaeac0bd-5e99-8480-5191-d402bde9a96c@redhat.com> (raw)
In-Reply-To: <dbe8cc44-ef30-3104-2bd3-6a6fe4438ada@redhat.com>

On 09/09/19 21:15, Laszlo Ersek wrote:

> ... I've done some testing too. Applying the QEMU patch on top of
> 89ea03a7dc83, my plan was:
> 
> - do not change OVMF, just see if it continues booting with the QEMU
> patch
> 
> - then negotiate bit#1 too, in step (1a) -- this is when I'd expect (3a)
> to break.
> 
> Unfortunately, the result is worse than that; even without negotiating
> bit#1 (i.e. in the baseline test), the firmware crashes (reboots) in
> step (3a). I've checked "info mtree", and all occurences of
> "smbase-blackhole" and "smbase-blackhole" are marked [disabled]. I'm not
> sure what's wrong with the baseline test (i.e. without negotiating
> bit#1). If I drop the patch (build QEMU at 89ea03a7dc83), then things
> work fine.

Sorry, there's a typo above: I pasted "smbase-blackhole" twice. The
second instance was meant to be "smbase-window". I checked all instances
of both regions in the info mtree output, I just fumbled the pasting.

Thanks
Laszlo