From mboxrd@z Thu Jan  1 00:00:00 1970
Authentication-Results: mx.groups.io;
 dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: imammedo@redhat.com)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 by groups.io with SMTP; Tue, 17 Sep 2019 06:11:26 -0700
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.redhat.com (Postfix) with ESMTPS id 90F85C060202;
	Tue, 17 Sep 2019 13:11:25 +0000 (UTC)
Received: from localhost (unknown [10.43.2.182])
	by smtp.corp.redhat.com (Postfix) with ESMTP id D4CED752D2;
	Tue, 17 Sep 2019 13:11:22 +0000 (UTC)
Date: Tue, 17 Sep 2019 15:11:21 +0200
From: "Igor Mammedov" <imammedo@redhat.com>
To: "Laszlo Ersek" <lersek@redhat.com>
Cc: devel@edk2.groups.io, qemu-devel@nongnu.org, yingwen.chen@intel.com,
 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: [edk2-devel] [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address
Message-ID: <20190917151121.41a199dc@redhat.com>
In-Reply-To: <8ed1ab55-d5ee-9703-dd28-cf50fbda5408@redhat.com>
References: <add488d0-df13-830f-28c5-c7232ccb741f@redhat.com>
	<20190905154925.30478-1-imammedo@redhat.com>
	<dbe8cc44-ef30-3104-2bd3-6a6fe4438ada@redhat.com>
	<20190910175841.176b26e4@redhat.com>
	<8ed1ab55-d5ee-9703-dd28-cf50fbda5408@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 17 Sep 2019 13:11:25 +0000 (UTC)
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 11 Sep 2019 19:30:46 +0200
"Laszlo Ersek" <lersek@redhat.com> wrote:

> On 09/10/19 17:58, Igor Mammedov wrote:
> > On Mon, 9 Sep 2019 21:15:44 +0200
> > Laszlo Ersek <lersek@redhat.com> wrote:  
> 
> [...]
> 
> > It looks like fwcfg smi feature negotiation isn't reusable in this case.
> > I'd prefer not to add another device just for another SMI feature
> > negotiation/activation.  
> 
> I thought it could be a register on the new CPU hotplug controller that
> we're going to need anyway (if I understand correctly, at least).
If we don't have to 'park' hotplugged CPUs, then I don't see a need for
an extra controller.


> But:
> 
> > How about stealing reserved register from pci-host similar to your
> > extended TSEG commit (2f295167 q35/mch: implement extended TSEG sizes)?
> > (Looking into spec can (ab)use 0x58 or 0x59 register)  
> 
> Yes, that should work.
> 
> In fact, I had considered 0x58 / 0x59 when looking for unused registers
> for extended TSEG configuration:
> 
> http://mid.mail-archive.com/d8802612-0b11-776f-b209-53bbdaf67515@redhat.com
> 
> So I'm OK with this, thank you.
Thanks for the tip!
... patches with a stolen register are on the way to mail-list.