From mboxrd@z Thu Jan  1 00:00:00 1970
Authentication-Results: mx.groups.io;
 dkim=missing; spf=pass (domain: redhat.com, ip: 209.85.221.43, mailfrom: pbonzini@redhat.com)
Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43])
 by groups.io with SMTP; Thu, 15 Aug 2019 09:24:56 -0700
Received: by mail-wr1-f43.google.com with SMTP id g17so2734870wrr.5
        for <devel@edk2.groups.io>; Thu, 15 Aug 2019 09:24:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id
         :date:user-agent:mime-version:in-reply-to:content-language
         :content-transfer-encoding;
        bh=bsE7YcO/81SljH9WTYeio0bxXW8xTJPwHm72S2QtOGY=;
        b=EhZPunCXfwXSs534Y/C+NAr2aRQyCMOU8SH/Qw7pVWz0XH0REeolGYRPjHvQnQXV40
         9kH2VGckMgQLo20A7HyNib63sQ+D+VVFyrhZ2/bt8s61Qa+0gJh/1vGdjfwur77NPWra
         B6AH46xNL5qbE3EwxST5RMD3j9WruW/IUYYZNGISuhoqFdmVrtaAnL3b6bb1vP7fQxgj
         XkBGLcHtopr6Qmg+GAEv6dEcSs9cIhtAsn54rLrqu4JpGYqiOtjSmfO5TNWGVnwopVG2
         E6mYxRcDX7UFuRcwZMzCdDIJiMGR3rjqdj74cgmCzWKIvT6IKbXPeC1ZLWaCR2osz6+Z
         qmPg==
X-Gm-Message-State: APjAAAVXPn8vy3NEolgCxV5Hgti5FDjU7TsTJWgOVlwc7rXyftO1J4mc
	zB0x7KFUS7uSyuVKj5VYIJg+CQ==
X-Google-Smtp-Source: APXvYqzIQ/J8tOj6X0wcB5Zval1alav7h8wrK4DgRqkn8QYVPGirAPFhAD/pqMb1lPDqVXzaGtmgcg==
X-Received: by 2002:a5d:678a:: with SMTP id v10mr6123660wru.116.1565886295041;
        Thu, 15 Aug 2019 09:24:55 -0700 (PDT)
Return-Path: <pbonzini@redhat.com>
Received: from ?IPv6:2001:b07:6468:f312:2cae:66cd:dd43:92d9? ([2001:b07:6468:f312:2cae:66cd:dd43:92d9])
        by smtp.gmail.com with ESMTPSA id e4sm5452409wrh.39.2019.08.15.09.24.54
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 15 Aug 2019 09:24:54 -0700 (PDT)
Subject: Re: CPU hotplug using SMM with QEMU+OVMF
To: Igor Mammedov <imammedo@redhat.com>
Cc: "Yao, Jiewen" <jiewen.yao@intel.com>, Laszlo Ersek <lersek@redhat.com>,
 edk2-devel-groups-io <devel@edk2.groups.io>,
 edk2-rfc-groups-io <rfc@edk2.groups.io>,
 qemu devel list <qemu-devel@nongnu.org>,
 "Chen, Yingwen" <yingwen.chen@intel.com>,
 "Nakajima, Jun" <jun.nakajima@intel.com>,
 Boris Ostrovsky <boris.ostrovsky@oracle.com>,
 Joao Marcal Lemos Martins <joao.m.martins@oracle.com>,
 Phillip Goerl <phillip.goerl@oracle.com>
References: <8091f6e8-b1ec-f017-1430-00b0255729f4@redhat.com>
 <effa5e32-be1e-4703-4419-8866b7754e2d@redhat.com>
 <74D8A39837DF1E4DA445A8C0B3885C503F75B680@shsmsx102.ccr.corp.intel.com>
 <047801f8-624a-2300-3cf7-1daa1395ce59@redhat.com>
 <20190815180733.4b396b5d@redhat.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Openpgp: preference=signencrypt
Message-ID: <f6c58790-7298-d991-844e-48f4a9dc8937@redhat.com>
Date: Thu, 15 Aug 2019 18:24:53 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20190815180733.4b396b5d@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit

On 15/08/19 18:07, Igor Mammedov wrote:
> Looking at Q35 code and Seabios SMM relocation as example, if I see it
> right QEMU has:
>     - SMRAM is aliased from DRAM at 0xa0000
>     - and TSEG steals from the top of low RAM when configured
> 
> Now problem is that default SMBASE at 0x30000 isn't backed by anything
> in SMRAM address space and default SMI entry falls-through to the same
> location in System address space.
> 
> The later is not trusted and entry into SMM mode will corrupt area + might
> jump to 'random' SMI handler (hence save/restore code in Seabios).
> 
> Here is an idea, can we map a memory region at 0x30000 in SMRAM address
> space with relocation space/code reserved. It could be a part of TSEG
> (so we don't have to invent ABI to configure that)?

No, there could be real mode code using it.  What we _could_ do is
initialize SMBASE to 0xa0000, but I think it's better to not deviate too
much from processor behavior (even if it's admittedly a 20-years legacy
that doesn't make any sense).

Paolo