Received-SPF: pass (google.com: domain of linux-kernel+bounces-147730-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <638ed26f-cd00-4a10-bd29-3f568b311da0@oracle.com>
Date: Tue, 16 Apr 2024 19:02:30 -0400
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] KVM/x86: Do not clear SIPI while in SMM
To: Sean Christopherson <seanjc@google.com>,
        Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20240416204729.2541743-1-boris.ostrovsky@oracle.com>
 <c7091688-8af5-4e70-b2d7-6d0a7134dbbe@redhat.com>
 <66cc2113-3417-42d0-bf47-d707816cbb53@oracle.com>
 <CABgObfZ-dFnWK46pyvuaO8TKEKC5pntqa1nXm-7Cwr0rpg5a3w@mail.gmail.com>
 <Zh74XcF2xWSq7_ZA@google.com>
Content-Language: en-US
From: boris.ostrovsky@oracle.com
In-Reply-To: <Zh74XcF2xWSq7_ZA@google.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?ZDZpMzByYWIxdDdBUkZzZkZUN1EwRHk4bjdmQ1JRK2F6NExYNXpTZWd2TGlQ?=
 =?utf-8?B?c3Rtb2NQa1ovOWk3eW5BWUpwT0tmNkpYV1hBNlJsalhuRDhhS245OVBCVGo0?=
 =?utf-8?B?QUlMTDdScXJFc2pRd3ZaTVVIdGxxMk5oTVl4b3A1RVNtN2dJWHJ4OVB6dUli?=
 =?utf-8?B?dzFNbE9IaHZIeG5wMldWVUg5ei9JaUJaOFBPL0FiNzV6d1lBTHZaenBrMU5y?=
 =?utf-8?B?MENrMWtPL0Q0Wjc0MFNEcXY5S1JlbzJ6TGJWSE5aUXBCMm1TS09rMitGajUy?=
 =?utf-8?B?VlZsVVorZXUrM1BvRWpZdWo3V2p3RXlkQWwxWHVKUGxCR2Y5aUM2aEdzNHR2?=
 =?utf-8?B?QkppemdYVXp3bmpFT2psVER2Sk9FTTFRakRCYThaQlZoL2R2SzUyNk0zZlJt?=
 =?utf-8?B?SGNkZ0l4ampHbFZyUE41dC9YejNSb0xTZXEvcWJ4UGhyQnhydFlTOTB2ZmUz?=
 =?utf-8?B?UGx5UG5rMVBjbHRvb2ovM0ZlMGcxUmRYMHBYVUdVaVVPL2dLcHM0cktSenl2?=
 =?utf-8?B?UWpLRUdpTGU5ckpia3F1Y1BkbCt3TklvejBPT3JaemtIVUJoMlFqNWlOMFR1?=
 =?utf-8?B?TFJDRkRtbUxuYm5jemlpSkRWdTlTYXlqV0RySTd0WE1Db29nLzNSTi85MERC?=
 =?utf-8?B?U09GR2N2VGpPZ25GU3MvTnU1MXNrWXpSL1lFZnJ1d251N21NS2w2Wkl6QmNH?=
 =?utf-8?B?MEp6SVNqRTlNWm1MUzFqYk5lZktTaDd2NW9pdm1weitjd3NwNUczMlo2cGtR?=
 =?utf-8?B?VktLMlRaVFRCUUZRcGFnczVma3dRUEh0eEN3bVVBNkpSR0p3VjRpbjI2bHpJ?=
 =?utf-8?B?T2xvRXZJYlIrbmdtYmtJdmQvTjM4aEZlNGUreGFJdFBFWnNMVlRxU0hacFl0?=
 =?utf-8?B?RzRUS2NxZ1luVGhBTFVrdEd0a1pwcmJJYjlmaUpQdTFZSmxZZVMzVzJoWWM4?=
 =?utf-8?B?RWJPMmNLUTdOM3F5MHl4U0RiOFlvbjc2R2tmWm5INFhqaFNXb3Y4M3ZNZjFO?=
 =?utf-8?B?cS9jUjhFaFpVOVlJT29mOWdlVVEwR0NicU1wdldXMzc3ZnFrYVd2N01NVVRk?=
 =?utf-8?B?SjRScTRYSTBKUjVEWFN1QUdNRUVCQWdNd3Awbmx4VzFUeVZpbThkS3dGZnZz?=
 =?utf-8?B?KzdUSGx2ampaMTdUR29JQWVrUU54UnBmcTZCMndRY0I0QmU1aU5MZld3MkQ3?=
 =?utf-8?B?VUtqN2NrY2ZnZEo3MEwwbWlHQTVLOUNsdHhnWVQzc2lCNCt6Tk90bDNDc0Vo?=
 =?utf-8?B?cjRKNllzRXZMbTFhVkM1WUxueEt2RmNKWjlGK1EzZER3SUF6c0UyN3Ivb1hy?=
 =?utf-8?B?T2pkemNMcmpnSG9KVktQKy9MT1JNeE96bWk2WGd3UnlEL1hNU0s5UlU2Y3Mx?=
 =?utf-8?B?Q3o2Uzl2ODhBUStOR1RVeE1uVmFyZE1EYnMvWHo2ZG5KcXd6VjRkNTR0SlVC?=
 =?utf-8?B?dGtFMThkaWRlWnBxSVdjbDg5K3BPdy9yRGQ5aWdZdHlRNDdBZ2VHZ3NSYnZT?=
 =?utf-8?B?MUR4azl6RkgzMVV5bThhb2NMb215QnRxUG5DUlJ2N0RXNlluSUtFZHlwZ2kz?=
 =?utf-8?B?bDY5ZXl2MzlwSFNwUU1FaWxxT1JoU09mRVpYUy9KY2dnMUlsQkEyTGhVeWwr?=
 =?utf-8?B?Ty9kdzNhS0UzS0pWNkV4bERPYlU1MWFaOHJjeFNFYmZtRjZ4VzczVG5aYnJ6?=
 =?utf-8?B?M2g4Sjc4MzYyMkRIRFVZV2JxV0JUSHV5eS8zYnl2TmwwYTdvWi9saUNhMnlx?=
 =?utf-8?B?azFtUUpaOU5SWjg0aVVleTBYWWhqT0VKRGZJM2NtVzl4MGR0UTZ0YVBhRWtS?=
 =?utf-8?B?N2NORVVDM0ZMQlhPOXQ5Nm10RTBLNHUyeWdPbmN5U2FDL2FubjFocGJtNTFs?=
 =?utf-8?B?dHdFRktKM2JndytzSzhzVHh2Q1J3OUovMDJRdFJIKytLV0xyc3ViaGFzS0U1?=
 =?utf-8?B?bit1ZGsza0lvVnlKMU9zVnpvdlFFMjh3MkpHMUF4dnJCWkhNakM2RTVrMDZs?=
 =?utf-8?B?WHV5T2haVGtoREt4L1FhTDVlV0dWSXZldWpvZVpNUGpUSE92NENsZ1JsKzVO?=
 =?utf-8?B?ZTd5YXN6Q2grcFdNRGZXVkRPUHE2eGgxUGd6V1RhVnA0V2pyeFZ0OFFQa1RO?=
 =?utf-8?B?bDhSRk9DVnZwbGJSSEwrbHV1dHpVZmZ1RlFHM0dnaEhkZmZncVRScTAwQXVt?=
 =?utf-8?B?VHc9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	8DtIQAhP0QedfbNcb7S6IJ+bDvVB5Mylb0PFZRvtwGKNbTxsf38xxjMn5Rb9u2HNGLOViwvQSEos56nNDQaQQrd8oGRQt7HraoqJEMEqjUO3c1G9zih7tSJ8Rb/dFMAmXfS+P286FPU7PX7Phuk8ZWjCHFENdC+kVEmZJ9EMj1P8yafwEshq3Qd4NRrJE5Q8dC1EEW4vHgbIroRjnNSlbOZeUjPbyLNH9HnnkHFp6J+t3OD6RsoDf1l9E5uiHzaPW99Qr5RWt71sXcuKz3g4c8EvuiVBY/16vc02pGZis1GeUWJAtHXblsJxTMZgQaQixg6T2aXUzMFVUVh3Vf0x9pCpEmL/WvW0zzGIYw4StocEwp1+TpgMo9bLEdqGz/H31FN/vvcTmpKBcrlrMIVYsj/7GM+xYRGmiRv1GbaCCWCY7S2886KajS0Uesl7d/1yudIJAbTMT5LP9ZqC7acVY75LooHoRIdqre1f2PKNcVYTG1TBW7ErUHfydnyZrcNrjMy0T+yaBTlWHjzoXrNpehp+5EIO0LfUCybFfHaC0CGyZcPA8hIuk1Ad6/VpuO0uq41jCIAvOg9yC57HVAvUNqxtkWT+oDvdiGTuMbU7tXA=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 772cfd3c-f5ea-4257-bf9f-08dc5e694c07
X-MS-Exchange-CrossTenant-AuthSource: BLAPR10MB5009.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2024 23:02:32.0555
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: OYsnT31Zo3EvKbmwg5ox247O5q7L7oblYsXfs+yOAx7B+fOgYgN4M7imEVfowC0gR7S915rgYN8iTGtznyEUc7suj29fGuWBmZIBsNGRqas=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR10MB4230
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-04-16_18,2024-04-16_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxscore=0 mlxlogscore=999
 suspectscore=0 adultscore=0 phishscore=0 bulkscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2404010000
 definitions=main-2404160149
X-Proofpoint-ORIG-GUID: hc9_GJCjklrMhv5KP1RXzjRy8Egjv_rZ
X-Proofpoint-GUID: hc9_GJCjklrMhv5KP1RXzjRy8Egjv_rZ


On 4/16/24 6:14 PM, Sean Christopherson wrote:
> On Wed, Apr 17, 2024, Paolo Bonzini wrote:
>> On Tue, Apr 16, 2024 at 10:57 PM <boris.ostrovsky@oracle.com> wrote:
>>> On 4/16/24 4:53 PM, Paolo Bonzini wrote:
>>>> On 4/16/24 22:47, Boris Ostrovsky wrote:
>>>>> Keeping the SIPI pending avoids this scenario.
>>>>
>>>> This is incorrect - it's yet another ugly legacy facet of x86, but we
>>>> have to live with it.  SIPI is discarded because the code is supposed
>>>> to retry it if needed ("INIT-SIPI-SIPI").
>>>
>>> I couldn't find in the SDM/APM a definitive statement about whether SIPI
>>> is supposed to be dropped.
>>
>> I think the manual is pretty consistent that SIPIs are never latched,
>> they're only ever used in wait-for-SIPI state.
> 
> Ya, the "Interrupt Command Register (ICR)" section for "110 (Start-Up)" explicitly
> says it's software's responsibility to detect whether or not the SIPI was delivered,
> and to resend SIPI(s) if needed.
> 
>    IPIs sent with this delivery mode are not automatically retried if the source
>    APIC is unable to deliver it. It is up to the software to determine if the
>    SIPI was not successfully delivered and to reissue the SIPI if necessary.


Right, I saw that. I was hoping to see something about SIPI being 
dropped. IOW my question was what happens to a SIPI that was delivered 
to a processor in SMM and not what should I do if it wasn't.

-boris