All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
@ 2018-06-13  9:58 Juergen Gross
  2018-06-13 10:05 ` [Xen-devel] " Jan Beulich
                   ` (3 more replies)
  0 siblings, 4 replies; 17+ messages in thread
From: Juergen Gross @ 2018-06-13  9:58 UTC (permalink / raw)
  To: linux-kernel, xen-devel; +Cc: boris.ostrovsky, Juergen Gross

Using privcmd_call() for a singleton multicall seems to be wrong, as
privcmd_call() is using stac()/clac() to enable hypervisor access to
Linux user space.

Add a new xen_single_call() function to be use for that purpose.

Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/xen/hypercall.h | 25 +++++++++++++++++++------
 arch/x86/xen/multicalls.c            |  6 +++---
 2 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
index bfd882617613..6b2f90a0b149 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -209,24 +209,37 @@ extern struct { char _entry[32]; } hypercall_page[];
 })
 
 static inline long
-privcmd_call(unsigned call,
-	     unsigned long a1, unsigned long a2,
-	     unsigned long a3, unsigned long a4,
-	     unsigned long a5)
+xen_single_call(unsigned int call,
+		unsigned long a1, unsigned long a2,
+		unsigned long a3, unsigned long a4,
+		unsigned long a5)
 {
 	__HYPERCALL_DECLS;
 	__HYPERCALL_5ARG(a1, a2, a3, a4, a5);
 
-	stac();
 	asm volatile(CALL_NOSPEC
 		     : __HYPERCALL_5PARAM
 		     : [thunk_target] "a" (&hypercall_page[call])
 		     : __HYPERCALL_CLOBBER5);
-	clac();
 
 	return (long)__res;
 }
 
+static inline long
+privcmd_call(unsigned int call,
+	     unsigned long a1, unsigned long a2,
+	     unsigned long a3, unsigned long a4,
+	     unsigned long a5)
+{
+	long res;
+
+	stac();
+	res = xen_single_call(call, a1, a2, a3, a4, a5);
+	clac();
+
+	return res;
+}
+
 static inline int
 HYPERVISOR_set_trap_table(struct trap_info *table)
 {
diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c
index dc502ca8263e..2bce7958ce8b 100644
--- a/arch/x86/xen/multicalls.c
+++ b/arch/x86/xen/multicalls.c
@@ -80,9 +80,9 @@ void xen_mc_flush(void)
 		   and just do the call directly. */
 		mc = &b->entries[0];
 
-		mc->result = privcmd_call(mc->op,
-					  mc->args[0], mc->args[1], mc->args[2], 
-					  mc->args[3], mc->args[4]);
+		mc->result = xen_single_call(mc->op, mc->args[0], mc->args[1],
+					     mc->args[2], mc->args[3],
+					     mc->args[4]);
 		ret = mc->result < 0;
 		break;
 
-- 
2.13.7


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [Xen-devel] [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
  2018-06-13  9:58 [PATCH] xen: don't use privcmd_call() from xen_mc_flush() Juergen Gross
@ 2018-06-13 10:05 ` Jan Beulich
  2018-06-13 10:20   ` Jan Beulich
                     ` (2 more replies)
  2018-06-13 10:05 ` Jan Beulich
                   ` (2 subsequent siblings)
  3 siblings, 3 replies; 17+ messages in thread
From: Jan Beulich @ 2018-06-13 10:05 UTC (permalink / raw)
  To: Juergen Gross; +Cc: xen-devel, Boris Ostrovsky, linux-kernel

>>> On 13.06.18 at 11:58, <jgross@suse.com> wrote:
> Using privcmd_call() for a singleton multicall seems to be wrong, as
> privcmd_call() is using stac()/clac() to enable hypervisor access to
> Linux user space.
> 
> Add a new xen_single_call() function to be use for that purpose.
> 
> Reported-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
  2018-06-13  9:58 [PATCH] xen: don't use privcmd_call() from xen_mc_flush() Juergen Gross
  2018-06-13 10:05 ` [Xen-devel] " Jan Beulich
@ 2018-06-13 10:05 ` Jan Beulich
  2018-08-07 13:11 ` Juergen Gross
  2018-08-07 13:11 ` Juergen Gross
  3 siblings, 0 replies; 17+ messages in thread
From: Jan Beulich @ 2018-06-13 10:05 UTC (permalink / raw)
  To: Juergen Gross; +Cc: xen-devel, Boris Ostrovsky, linux-kernel

>>> On 13.06.18 at 11:58, <jgross@suse.com> wrote:
> Using privcmd_call() for a singleton multicall seems to be wrong, as
> privcmd_call() is using stac()/clac() to enable hypervisor access to
> Linux user space.
> 
> Add a new xen_single_call() function to be use for that purpose.
> 
> Reported-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Xen-devel] [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
  2018-06-13 10:05 ` [Xen-devel] " Jan Beulich
@ 2018-06-13 10:20   ` Jan Beulich
  2018-06-13 10:20   ` Jan Beulich
       [not found]   ` <5B20EFE102000078001CACD4@suse.com>
  2 siblings, 0 replies; 17+ messages in thread
From: Jan Beulich @ 2018-06-13 10:20 UTC (permalink / raw)
  To: Juergen Gross; +Cc: xen-devel, Boris Ostrovsky, linux-kernel

>>> On 13.06.18 at 12:05, <JBeulich@suse.com> wrote:
>>>> On 13.06.18 at 11:58, <jgross@suse.com> wrote:
>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>> Linux user space.
>> 
>> Add a new xen_single_call() function to be use for that purpose.
>> 
>> Reported-by: Jan Beulich <jbeulich@suse.com>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

Actually I've only now realized that this isn't a real problem right now:
PV can't use SMAP (we don't provide a virtualized version of it), and
HVM/PVH can't use multicalls (which may have to change for PVH Dom0,
so having the change in place is helpful anyway), so the whole
in-kernel logic to collect and issue batches should be unreachable there.

But perhaps the commit message would benefit from a little bit of
re-wording.

Jan



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
  2018-06-13 10:05 ` [Xen-devel] " Jan Beulich
  2018-06-13 10:20   ` Jan Beulich
@ 2018-06-13 10:20   ` Jan Beulich
       [not found]   ` <5B20EFE102000078001CACD4@suse.com>
  2 siblings, 0 replies; 17+ messages in thread
From: Jan Beulich @ 2018-06-13 10:20 UTC (permalink / raw)
  To: Juergen Gross; +Cc: xen-devel, Boris Ostrovsky, linux-kernel

>>> On 13.06.18 at 12:05, <JBeulich@suse.com> wrote:
>>>> On 13.06.18 at 11:58, <jgross@suse.com> wrote:
>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>> Linux user space.
>> 
>> Add a new xen_single_call() function to be use for that purpose.
>> 
>> Reported-by: Jan Beulich <jbeulich@suse.com>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>

Actually I've only now realized that this isn't a real problem right now:
PV can't use SMAP (we don't provide a virtualized version of it), and
HVM/PVH can't use multicalls (which may have to change for PVH Dom0,
so having the change in place is helpful anyway), so the whole
in-kernel logic to collect and issue batches should be unreachable there.

But perhaps the commit message would benefit from a little bit of
re-wording.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Xen-devel] [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
       [not found]   ` <5B20EFE102000078001CACD4@suse.com>
@ 2018-06-13 11:12     ` Juergen Gross
  2018-06-13 12:55         ` Jan Beulich
  2018-06-13 11:12     ` Juergen Gross
  1 sibling, 1 reply; 17+ messages in thread
From: Juergen Gross @ 2018-06-13 11:12 UTC (permalink / raw)
  To: Jan Beulich; +Cc: xen-devel, Boris Ostrovsky, lkml

On 13/06/18 12:20, Jan Beulich wrote:
>>>> On 13.06.18 at 12:05, <JBeulich@suse.com> wrote:
>>>>> On 13.06.18 at 11:58, <jgross@suse.com> wrote:
>>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>>> Linux user space.
>>>
>>> Add a new xen_single_call() function to be use for that purpose.
>>>
>>> Reported-by: Jan Beulich <jbeulich@suse.com>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>
>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> 
> Actually I've only now realized that this isn't a real problem right now:
> PV can't use SMAP (we don't provide a virtualized version of it), and
> HVM/PVH can't use multicalls (which may have to change for PVH Dom0,
> so having the change in place is helpful anyway), so the whole
> in-kernel logic to collect and issue batches should be unreachable there.
> 
> But perhaps the commit message would benefit from a little bit of
> re-wording.

Hmm, right.

What about:

"Using privcmd_call() for a singleton multicall seems to be wrong, as
 privcmd_call() is using stac()/clac() to enable hypervisor access to
 Linux user space.

 Even if currently not a problem (pv domains can't use SMAP while HVM
 and PVH domains can't use multicalls) things might change when
 PVH dom0 support is added to the kernel."


Juergen

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
       [not found]   ` <5B20EFE102000078001CACD4@suse.com>
  2018-06-13 11:12     ` [Xen-devel] " Juergen Gross
@ 2018-06-13 11:12     ` Juergen Gross
  1 sibling, 0 replies; 17+ messages in thread
From: Juergen Gross @ 2018-06-13 11:12 UTC (permalink / raw)
  To: Jan Beulich; +Cc: xen-devel, Boris Ostrovsky, lkml

On 13/06/18 12:20, Jan Beulich wrote:
>>>> On 13.06.18 at 12:05, <JBeulich@suse.com> wrote:
>>>>> On 13.06.18 at 11:58, <jgross@suse.com> wrote:
>>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>>> Linux user space.
>>>
>>> Add a new xen_single_call() function to be use for that purpose.
>>>
>>> Reported-by: Jan Beulich <jbeulich@suse.com>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>
>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> 
> Actually I've only now realized that this isn't a real problem right now:
> PV can't use SMAP (we don't provide a virtualized version of it), and
> HVM/PVH can't use multicalls (which may have to change for PVH Dom0,
> so having the change in place is helpful anyway), so the whole
> in-kernel logic to collect and issue batches should be unreachable there.
> 
> But perhaps the commit message would benefit from a little bit of
> re-wording.

Hmm, right.

What about:

"Using privcmd_call() for a singleton multicall seems to be wrong, as
 privcmd_call() is using stac()/clac() to enable hypervisor access to
 Linux user space.

 Even if currently not a problem (pv domains can't use SMAP while HVM
 and PVH domains can't use multicalls) things might change when
 PVH dom0 support is added to the kernel."


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Xen-devel] [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
  2018-06-13 11:12     ` [Xen-devel] " Juergen Gross
@ 2018-06-13 12:55         ` Jan Beulich
  0 siblings, 0 replies; 17+ messages in thread
From: Jan Beulich @ 2018-06-13 12:55 UTC (permalink / raw)
  To: Juergen Gross; +Cc: xen-devel, Boris Ostrovsky, linux-kernel

>>> On 13.06.18 at 13:12, <jgross@suse.com> wrote:
> On 13/06/18 12:20, Jan Beulich wrote:
>>>>> On 13.06.18 at 12:05, <JBeulich@suse.com> wrote:
>>>>>> On 13.06.18 at 11:58, <jgross@suse.com> wrote:
>>>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>>>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>>>> Linux user space.
>>>>
>>>> Add a new xen_single_call() function to be use for that purpose.
>>>>
>>>> Reported-by: Jan Beulich <jbeulich@suse.com>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>
>>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>> 
>> Actually I've only now realized that this isn't a real problem right now:
>> PV can't use SMAP (we don't provide a virtualized version of it), and
>> HVM/PVH can't use multicalls (which may have to change for PVH Dom0,
>> so having the change in place is helpful anyway), so the whole
>> in-kernel logic to collect and issue batches should be unreachable there.
>> 
>> But perhaps the commit message would benefit from a little bit of
>> re-wording.
> 
> Hmm, right.
> 
> What about:
> 
> "Using privcmd_call() for a singleton multicall seems to be wrong, as
>  privcmd_call() is using stac()/clac() to enable hypervisor access to
>  Linux user space.
> 
>  Even if currently not a problem (pv domains can't use SMAP while HVM
>  and PVH domains can't use multicalls) things might change when
>  PVH dom0 support is added to the kernel."

SGTM

Jan




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
@ 2018-06-13 12:55         ` Jan Beulich
  0 siblings, 0 replies; 17+ messages in thread
From: Jan Beulich @ 2018-06-13 12:55 UTC (permalink / raw)
  To: Juergen Gross; +Cc: xen-devel, Boris Ostrovsky, linux-kernel

>>> On 13.06.18 at 13:12, <jgross@suse.com> wrote:
> On 13/06/18 12:20, Jan Beulich wrote:
>>>>> On 13.06.18 at 12:05, <JBeulich@suse.com> wrote:
>>>>>> On 13.06.18 at 11:58, <jgross@suse.com> wrote:
>>>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>>>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>>>> Linux user space.
>>>>
>>>> Add a new xen_single_call() function to be use for that purpose.
>>>>
>>>> Reported-by: Jan Beulich <jbeulich@suse.com>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>
>>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>> 
>> Actually I've only now realized that this isn't a real problem right now:
>> PV can't use SMAP (we don't provide a virtualized version of it), and
>> HVM/PVH can't use multicalls (which may have to change for PVH Dom0,
>> so having the change in place is helpful anyway), so the whole
>> in-kernel logic to collect and issue batches should be unreachable there.
>> 
>> But perhaps the commit message would benefit from a little bit of
>> re-wording.
> 
> Hmm, right.
> 
> What about:
> 
> "Using privcmd_call() for a singleton multicall seems to be wrong, as
>  privcmd_call() is using stac()/clac() to enable hypervisor access to
>  Linux user space.
> 
>  Even if currently not a problem (pv domains can't use SMAP while HVM
>  and PVH domains can't use multicalls) things might change when
>  PVH dom0 support is added to the kernel."

SGTM

Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
  2018-06-13  9:58 [PATCH] xen: don't use privcmd_call() from xen_mc_flush() Juergen Gross
                   ` (2 preceding siblings ...)
  2018-08-07 13:11 ` Juergen Gross
@ 2018-08-07 13:11 ` Juergen Gross
  2018-08-07 14:02   ` Boris Ostrovsky
  2018-08-07 14:02   ` Boris Ostrovsky
  3 siblings, 2 replies; 17+ messages in thread
From: Juergen Gross @ 2018-08-07 13:11 UTC (permalink / raw)
  To: linux-kernel, xen-devel; +Cc: boris.ostrovsky

On 13/06/18 11:58, Juergen Gross wrote:
> Using privcmd_call() for a singleton multicall seems to be wrong, as
> privcmd_call() is using stac()/clac() to enable hypervisor access to
> Linux user space.
> 
> Add a new xen_single_call() function to be use for that purpose.
> 
> Reported-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>

Boris, any objections?


Juergen

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
  2018-06-13  9:58 [PATCH] xen: don't use privcmd_call() from xen_mc_flush() Juergen Gross
  2018-06-13 10:05 ` [Xen-devel] " Jan Beulich
  2018-06-13 10:05 ` Jan Beulich
@ 2018-08-07 13:11 ` Juergen Gross
  2018-08-07 13:11 ` Juergen Gross
  3 siblings, 0 replies; 17+ messages in thread
From: Juergen Gross @ 2018-08-07 13:11 UTC (permalink / raw)
  To: linux-kernel, xen-devel; +Cc: boris.ostrovsky

On 13/06/18 11:58, Juergen Gross wrote:
> Using privcmd_call() for a singleton multicall seems to be wrong, as
> privcmd_call() is using stac()/clac() to enable hypervisor access to
> Linux user space.
> 
> Add a new xen_single_call() function to be use for that purpose.
> 
> Reported-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>

Boris, any objections?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
  2018-08-07 13:11 ` Juergen Gross
  2018-08-07 14:02   ` Boris Ostrovsky
@ 2018-08-07 14:02   ` Boris Ostrovsky
  2018-08-07 15:17     ` Juergen Gross
  2018-08-07 15:17     ` Juergen Gross
  1 sibling, 2 replies; 17+ messages in thread
From: Boris Ostrovsky @ 2018-08-07 14:02 UTC (permalink / raw)
  To: Juergen Gross, linux-kernel, xen-devel

On 08/07/2018 09:11 AM, Juergen Gross wrote:
> On 13/06/18 11:58, Juergen Gross wrote:
>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>> Linux user space.
>>
>> Add a new xen_single_call() function to be use for that purpose.
>>
>> Reported-by: Jan Beulich <jbeulich@suse.com>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
> Boris, any objections?


I think Jan wanted a change in commit message. I can commit with this:

"Using privcmd_call() for a singleton multicall seems to be wrong, as
 privcmd_call() is using stac()/clac() to enable hypervisor access to
 Linux user space.

 Even if currently not a problem (pv domains can't use SMAP while HVM
 and PVH domains can't use multicalls) things might change when
 PVH dom0 support is added to the kernel."


-boris


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
  2018-08-07 13:11 ` Juergen Gross
@ 2018-08-07 14:02   ` Boris Ostrovsky
  2018-08-07 14:02   ` Boris Ostrovsky
  1 sibling, 0 replies; 17+ messages in thread
From: Boris Ostrovsky @ 2018-08-07 14:02 UTC (permalink / raw)
  To: Juergen Gross, linux-kernel, xen-devel

On 08/07/2018 09:11 AM, Juergen Gross wrote:
> On 13/06/18 11:58, Juergen Gross wrote:
>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>> Linux user space.
>>
>> Add a new xen_single_call() function to be use for that purpose.
>>
>> Reported-by: Jan Beulich <jbeulich@suse.com>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
> Boris, any objections?


I think Jan wanted a change in commit message. I can commit with this:

"Using privcmd_call() for a singleton multicall seems to be wrong, as
 privcmd_call() is using stac()/clac() to enable hypervisor access to
 Linux user space.

 Even if currently not a problem (pv domains can't use SMAP while HVM
 and PVH domains can't use multicalls) things might change when
 PVH dom0 support is added to the kernel."


-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
  2018-08-07 14:02   ` Boris Ostrovsky
@ 2018-08-07 15:17     ` Juergen Gross
  2018-08-07 16:42       ` Boris Ostrovsky
  2018-08-07 16:42       ` Boris Ostrovsky
  2018-08-07 15:17     ` Juergen Gross
  1 sibling, 2 replies; 17+ messages in thread
From: Juergen Gross @ 2018-08-07 15:17 UTC (permalink / raw)
  To: Boris Ostrovsky, linux-kernel, xen-devel

On 07/08/18 16:02, Boris Ostrovsky wrote:
> On 08/07/2018 09:11 AM, Juergen Gross wrote:
>> On 13/06/18 11:58, Juergen Gross wrote:
>>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>>> Linux user space.
>>>
>>> Add a new xen_single_call() function to be use for that purpose.
>>>
>>> Reported-by: Jan Beulich <jbeulich@suse.com>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> Boris, any objections?
> 
> 
> I think Jan wanted a change in commit message. I can commit with this:
> 
> "Using privcmd_call() for a singleton multicall seems to be wrong, as
>  privcmd_call() is using stac()/clac() to enable hypervisor access to
>  Linux user space.
> 
>  Even if currently not a problem (pv domains can't use SMAP while HVM
>  and PVH domains can't use multicalls) things might change when
>  PVH dom0 support is added to the kernel."

This would be fine, thanks.


Juergen

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
  2018-08-07 14:02   ` Boris Ostrovsky
  2018-08-07 15:17     ` Juergen Gross
@ 2018-08-07 15:17     ` Juergen Gross
  1 sibling, 0 replies; 17+ messages in thread
From: Juergen Gross @ 2018-08-07 15:17 UTC (permalink / raw)
  To: Boris Ostrovsky, linux-kernel, xen-devel

On 07/08/18 16:02, Boris Ostrovsky wrote:
> On 08/07/2018 09:11 AM, Juergen Gross wrote:
>> On 13/06/18 11:58, Juergen Gross wrote:
>>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>>> Linux user space.
>>>
>>> Add a new xen_single_call() function to be use for that purpose.
>>>
>>> Reported-by: Jan Beulich <jbeulich@suse.com>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> Boris, any objections?
> 
> 
> I think Jan wanted a change in commit message. I can commit with this:
> 
> "Using privcmd_call() for a singleton multicall seems to be wrong, as
>  privcmd_call() is using stac()/clac() to enable hypervisor access to
>  Linux user space.
> 
>  Even if currently not a problem (pv domains can't use SMAP while HVM
>  and PVH domains can't use multicalls) things might change when
>  PVH dom0 support is added to the kernel."

This would be fine, thanks.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
  2018-08-07 15:17     ` Juergen Gross
  2018-08-07 16:42       ` Boris Ostrovsky
@ 2018-08-07 16:42       ` Boris Ostrovsky
  1 sibling, 0 replies; 17+ messages in thread
From: Boris Ostrovsky @ 2018-08-07 16:42 UTC (permalink / raw)
  To: Juergen Gross, linux-kernel, xen-devel

On 08/07/2018 11:17 AM, Juergen Gross wrote:
> On 07/08/18 16:02, Boris Ostrovsky wrote:
>> On 08/07/2018 09:11 AM, Juergen Gross wrote:
>>> On 13/06/18 11:58, Juergen Gross wrote:
>>>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>>>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>>>> Linux user space.
>>>>
>>>> Add a new xen_single_call() function to be use for that purpose.
>>>>
>>>> Reported-by: Jan Beulich <jbeulich@suse.com>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> Boris, any objections?
>>
>> I think Jan wanted a change in commit message. I can commit with this:
>>
>> "Using privcmd_call() for a singleton multicall seems to be wrong, as
>>  privcmd_call() is using stac()/clac() to enable hypervisor access to
>>  Linux user space.
>>
>>  Even if currently not a problem (pv domains can't use SMAP while HVM
>>  and PVH domains can't use multicalls) things might change when
>>  PVH dom0 support is added to the kernel."
> This would be fine, thanks.

Applied to for-linus-4.19

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] xen: don't use privcmd_call() from xen_mc_flush()
  2018-08-07 15:17     ` Juergen Gross
@ 2018-08-07 16:42       ` Boris Ostrovsky
  2018-08-07 16:42       ` Boris Ostrovsky
  1 sibling, 0 replies; 17+ messages in thread
From: Boris Ostrovsky @ 2018-08-07 16:42 UTC (permalink / raw)
  To: Juergen Gross, linux-kernel, xen-devel

On 08/07/2018 11:17 AM, Juergen Gross wrote:
> On 07/08/18 16:02, Boris Ostrovsky wrote:
>> On 08/07/2018 09:11 AM, Juergen Gross wrote:
>>> On 13/06/18 11:58, Juergen Gross wrote:
>>>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>>>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>>>> Linux user space.
>>>>
>>>> Add a new xen_single_call() function to be use for that purpose.
>>>>
>>>> Reported-by: Jan Beulich <jbeulich@suse.com>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> Boris, any objections?
>>
>> I think Jan wanted a change in commit message. I can commit with this:
>>
>> "Using privcmd_call() for a singleton multicall seems to be wrong, as
>>  privcmd_call() is using stac()/clac() to enable hypervisor access to
>>  Linux user space.
>>
>>  Even if currently not a problem (pv domains can't use SMAP while HVM
>>  and PVH domains can't use multicalls) things might change when
>>  PVH dom0 support is added to the kernel."
> This would be fine, thanks.

Applied to for-linus-4.19

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2018-08-07 16:41 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-13  9:58 [PATCH] xen: don't use privcmd_call() from xen_mc_flush() Juergen Gross
2018-06-13 10:05 ` [Xen-devel] " Jan Beulich
2018-06-13 10:20   ` Jan Beulich
2018-06-13 10:20   ` Jan Beulich
     [not found]   ` <5B20EFE102000078001CACD4@suse.com>
2018-06-13 11:12     ` [Xen-devel] " Juergen Gross
2018-06-13 12:55       ` Jan Beulich
2018-06-13 12:55         ` Jan Beulich
2018-06-13 11:12     ` Juergen Gross
2018-06-13 10:05 ` Jan Beulich
2018-08-07 13:11 ` Juergen Gross
2018-08-07 13:11 ` Juergen Gross
2018-08-07 14:02   ` Boris Ostrovsky
2018-08-07 14:02   ` Boris Ostrovsky
2018-08-07 15:17     ` Juergen Gross
2018-08-07 16:42       ` Boris Ostrovsky
2018-08-07 16:42       ` Boris Ostrovsky
2018-08-07 15:17     ` Juergen Gross

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.