* [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.