[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86/kexec: Fix kexec-reboot with CET active


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 8 Mar 2022 17:48:18 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=M3CUNcJZnIcenVxqE9hGpM55RqJyLk7VV5qHTzznDBY=; b=IoNhsawZSWcU9aQvVBYNbm023QLo0BciPuhGyoODzzrJ1gZBBzCO7DuRvI2fXO2U61XRnYsqhgkBwYQuYnzbhH/o0txE1Dl4bfuau0MxU2kBkMKwIAmUkGQvQtF/3nbRXQDJeLEJoowjXz1qfqxm1+dwEHJRAU2PEajs9VXIvbK1kbboTFjpqZiW6HZ+bty5uv/knsXrTEYVz4CS3df9tuvijv6wM9ICSz78KP8Rt4F8uCEWpWt5WNw5bYl3KKC+UOsJvRLqypl6juWcINST5UGNFO+nFSJIL28HxWWLiLX9HkKHi9lLDTiUH3LcFVgeodsF9wJjcIx3ZbpGl/setg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LjraGMx8suFMv4N25FYFBD6lWv1YLBejdaKISdEy14ggfpDFyQJIQo8pr8Nq3daOLwTO8rSDla2+ImbBIcubIvMBBNdUN1FLouvSVftX0lJmSvSmeNYQ47lmxmCp5ERMFLDiXz7qeIPbWHn8xWZ3DBJXSNCh70AyMOD3MNGgm7T3llnq7j8AoQ+Lh1N5BlEcDbde4LNMdmcYxKGFxuiuRQlbGFbL+xg15NJnwaNUKKR6sAuAYObQIfee8mFMaNaRJ3ojp16zpA/VD2vlrKlnNh3FD9m2vr8sR/OTmbjIgspqN+BZwDHeNtdiwuZs/Ck8alhRGggrkGP+jC5+R7PVDQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, David Vrabel <dvrabel@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 08 Mar 2022 16:48:31 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 08.03.2022 17:22, Andrew Cooper wrote:
> On 08/03/2022 08:15, Jan Beulich wrote:
>> On 07.03.2022 21:53, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/machine_kexec.c
>>> +++ b/xen/arch/x86/machine_kexec.c
>>> @@ -156,6 +156,16 @@ void machine_kexec(struct kexec_image *image)
>>>       */
>>>      local_irq_disable();
>>>  
>>> +    /* Reset CPUID masking and faulting to the host's default. */
>>> +    ctxt_switch_levelling(NULL);
>>> +
>>> +    /* Disable CET. */
>>> +    if ( read_cr4() & X86_CR4_CET )
>>> +    {
>>> +        wrmsrl(MSR_S_CET, 0);
>>> +        write_cr4(read_cr4() & ~X86_CR4_CET);
>>> +    }
>>> +
>>>      /* Now regular interrupts are disabled, we need to reduce the impact
>>>       * of interrupts not disabled by 'cli'.
>>>       *
>> Besides introducing somewhat of a disconnect between the comment in
>> context here and the earlier local_irq_disable(), is it really
>> necessary to do both actions with IRQs off?
> 
> We are a handful of instructions away from discarding Xen's context
> entirely.  IRQs are not a relevant concern.

Well, as said - the comment was what caught my eye. But as you appear to
think that slight disconnect is not an issue: I don't mean my remark to
be an objection. Feel free to commit with David's R-b.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.