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

Re: [PATCH] x86/Xen: make use of IBPB controlling VM assist


  • To: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 15 Feb 2023 09:31:37 +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=KVIM5suLFeTH2CsLZFTDkv0CpL4BN3DjyXX8/2ikmEw=; b=V4IMvoOZmNmpg3qlet0sjSfGej5SvLnfknkZCvIGSaFb7vsvvvvX3LYozJBSfj7Rz5FWw9xETXPb2VrZWWDyqyjTYMKd/6vfss27Ii+ZKhkgGpO/tFCZbrECeM+fJmoes4A2Cyq4F3zvBiLbN4h6OwOgzU/Jt5vQXWDFyLOiq8VJmC15FBnVLy5uIxzd5tBtFbgOJGiJuQelN5zylOKGIBCNp0huAKA1CHGz8r/8+WGMlyF+BnBF0J6snjlKO6Aq/RbmDJfgvjbxCljKV1jgNgsLKU04NF2MdHxwRDH+b1bSMK/bhdRoULP8DElZArsRl2jTibNJCQ810NfymXmbhg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G5VU1312sp8NrJIUl1riZ3dKLSr75d/JF3hQbW/O1k8MbrxLjBImGq0FD1hZeBW+2K3Z3DgsvGwHleopKEH/L21BnuHrh1ixWc+fMwYMfM4pL3O9MBsbSVLvy2xiEM5srytn827komVwL8B0XuduFXEbqrk9fnsMm6fkD0wBfH45x01tas3TzIXSIGgAHz1xicd8LqmwNK2hyLijAcsfkUvoHAajL4CFPm8+uSAnm/0qpw5IepU6dgrUV4O72YVjqGH5Ty84HAEm4cxZn0N5NIUfF7Z54dgbgRajn0KVb8XmxzCQINbVsjcK1mAQAGpO5bNy0snzRUhj/vwrXW8OWg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 15 Feb 2023 08:31:56 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 15.02.2023 01:07, Boris Ostrovsky wrote:
> 
> On 2/14/23 6:53 PM, Boris Ostrovsky wrote:
>>
>> On 2/14/23 11:13 AM, Jan Beulich wrote:
>>
>>> --- a/arch/x86/kernel/cpu/bugs.c
>>> +++ b/arch/x86/kernel/cpu/bugs.c
>>> @@ -18,6 +18,8 @@
>>>   #include <linux/pgtable.h>
>>>   #include <linux/bpf.h>
>>>   +#include <xen/xen.h>
>>> +
>>>   #include <asm/spec-ctrl.h>
>>>   #include <asm/cmdline.h>
>>>   #include <asm/bugs.h>
>>> @@ -32,6 +34,7 @@
>>>   #include <asm/intel-family.h>
>>>   #include <asm/e820/api.h>
>>>   #include <asm/hypervisor.h>
>>> +#include <asm/xen/hypervisor.h>
>>>   #include <asm/tlbflush.h>
>>>     #include "cpu.h"
>>> @@ -934,7 +937,8 @@ do_cmd_auto:
>>>           break;
>>>         case RETBLEED_MITIGATION_IBPB:
>>> -        setup_force_cpu_cap(X86_FEATURE_ENTRY_IBPB);
>>> +        if (!xen_pv_domain() || xen_vm_assist_ibpb(true))
>>
>>
>> Is this going to compile without CONFIG_XEN?

Yes. The declaration of xen_vm_assist_ibpb() is visible (satisfying
the compiler) and DCE will eliminate the call to the function due to
xen_pv_domain() being constant "false" in that case, avoiding any
linking issues. The interesting case here really is building with
XEN but without XEN_PV: That's why I needed to put the function in
enlighten.c. This wouldn't be needed if xen_pv_domain() was also
constant "false" in that case (just like xen_pvh_domain() is when
!XEN_PVH).

>> I also think these two conditions should be wrapped into something to limit 
>> exposure of non-Xen code to Xen-specific primitives.

I would have done so, if I had any halfway sensible idea on how to
go about doing so in this particular case. In the absence of that it
looked okay-ish to me to reference Xen functions directly here.

> Oh, and this needs x86 maintainers.

Eventually yes. But I would prefer to sort the above question first
(which I'm sure would have been raised by them, in perhaps more
harsh a way), hence the initially limited exposure.

Jan



 


Rackspace

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