From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Jork Loeser <Jork.Loeser@microsoft.com>
Cc: "devel\@linuxdriverproject.org" <devel@linuxdriverproject.org>,
"x86\@kernel.org" <x86@kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"KY Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH 6/7] x86/hyper-v: use hypercall for remove TLB flush
Date: Mon, 10 Apr 2017 19:21:34 +0200 [thread overview]
Message-ID: <87a87oqiu9.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <MWHPR21MB063911897C6E0286F3055A56F10C0@MWHPR21MB0639.namprd21.prod.outlook.com> (Jork Loeser's message of "Fri, 7 Apr 2017 20:46:13 +0000")
Jork Loeser <Jork.Loeser@microsoft.com> writes:
>> -----Original Message-----
>> From: Vitaly Kuznetsov [mailto:vkuznets@redhat.com]
>> Sent: Friday, April 7, 2017 04:27
>> To: devel@linuxdriverproject.org; x86@kernel.org
>> Cc: linux-kernel@vger.kernel.org; KY Srinivasan <kys@microsoft.com>;
>> Haiyang Zhang <haiyangz@microsoft.com>; Stephen Hemminger
>> <sthemmin@microsoft.com>; Thomas Gleixner <tglx@linutronix.de>; Ingo
>> Molnar <mingo@redhat.com>; H. Peter Anvin <hpa@zytor.com>; Steven
>> Rostedt <rostedt@goodmis.org>; Jork Loeser <Jork.Loeser@microsoft.com>
>> Subject: [PATCH 6/7] x86/hyper-v: use hypercall for remove TLB flush
>
>> diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c new file
>> mode 100644 index 0000000..fb487cb
>> --- /dev/null
>> +++ b/arch/x86/hyperv/mmu.c
>> @@ -0,0 +1,128 @@
>> +#include <linux/types.h>
>> +#include <linux/hyperv.h>
>> +#include <linux/slab.h>
>> +#include <asm/mshyperv.h>
>> +#include <asm/tlbflush.h>
>> +#include <asm/msr.h>
>> +#include <asm/fpu/api.h>
>> +
>> +/*
>> + * Arbitrary number; we need to pre-allocate per-cpu struct for doing
>> +TLB
>> + * flush hypercalls and we need to pick a size. '16' means we'll be
>> +able
>> + * to flush 16 * 4096 pages (256MB) with one hypercall.
>> + */
>> +#define HV_MMU_MAX_GVAS 16
>> +
>> +/* HvFlushVirtualAddressSpace*, HvFlushVirtualAddressList hypercalls */
>> +struct hv_flush_pcpu {
>> + struct {
>> + __u64 address_space;
>> + __u64 flags;
>> + __u64 processor_mask;
>> + __u64 gva_list[HV_MMU_MAX_GVAS];
>> + } flush;
>> +
>> + spinlock_t lock;
>> +};
> Does this need an alignment declaration, so that the flush portion never crosses a page boundary when allocated with alloc_percpu()?
>
Thanks for pointing this out! I would slightly prefer we use
__alloc_percpu() and specify something like roundup_pow_of_two()
alignment.
>> +
>> +static struct hv_flush_pcpu __percpu *pcpu_flush;
>> +
>> +static void hyperv_flush_tlb_others(const struct cpumask *cpus,
>> + struct mm_struct *mm, unsigned long
>> start,
>> + unsigned long end)
>> +{
>> + struct hv_flush_pcpu *flush;
>> + unsigned long cur, flags;
>> + u64 status = -1ULL;
>> + int cpu, vcpu, gva_n;
>> +
>> + if (!pcpu_flush || !hv_hypercall_pg)
>> + goto do_native;
>> +
>> + if (cpumask_empty(cpus))
>> + return;
>> +
>> + flush = this_cpu_ptr(pcpu_flush);
>> + spin_lock_irqsave(&flush->lock, flags);
>
> What purpose does the spinlock on the CPU-local struct serve? Would a
> local_irq_save() do?
Now I'm not sure why I put it here in the first place :-) Yes, it would
probably do.
> Could this be called from NMI context, such as from the debugger?
>
NMI - I don't think so, native function does smp_call_function_many()
which WARNs even if it's called with interrupts disabled.
> Could this be a long-running loop, e.g. due to a large start/end
> range? If so, consider disabling interrupts only in the inner loop /
> flush the entire space?
The decision for flushing the entire space should probably be done
elsewhere as it is not implementation-specific (and I think it's done
somewhere as I never see requests to flush more than 4096 pages in my
testing).
I can disable interrupts in the inner loop but we'll have to stash flags
and calculated cpu_mask to some local variables. This is not supposed to
be expensive.
--
Vitaly
next prev parent reply other threads:[~2017-04-10 17:21 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-07 11:26 [PATCH 0/7] Hyper-V: praravirtualized remote TLB flushing and hypercall improvements Vitaly Kuznetsov
2017-04-07 11:26 ` [PATCH 1/7] x86/hyperv: make hv_do_hypercall() inline Vitaly Kuznetsov
2017-04-07 19:38 ` Jork Loeser
2017-04-07 11:26 ` [PATCH 2/7] x86/hyper-v: fast hypercall implementation Vitaly Kuznetsov
2017-04-07 19:42 ` Jork Loeser
2017-04-10 9:07 ` Vitaly Kuznetsov
2017-04-10 14:45 ` Vitaly Kuznetsov
2017-04-10 17:14 ` Jork Loeser
2017-04-08 15:18 ` KY Srinivasan
2017-04-10 8:46 ` Vitaly Kuznetsov
2017-04-07 11:26 ` [PATCH 3/7] hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT Vitaly Kuznetsov
2017-04-07 11:26 ` [PATCH 4/7] x86/hyperv: implement rep hypercalls Vitaly Kuznetsov
2017-04-07 19:48 ` Jork Loeser
2017-04-10 9:00 ` Vitaly Kuznetsov
2017-04-07 11:26 ` [PATCH 5/7] hyper-v: globalize vp_index Vitaly Kuznetsov
2017-04-08 15:41 ` KY Srinivasan
2017-04-07 11:27 ` [PATCH 6/7] x86/hyper-v: use hypercall for remove TLB flush Vitaly Kuznetsov
2017-04-07 20:46 ` Jork Loeser
2017-04-10 17:21 ` Vitaly Kuznetsov [this message]
2017-04-08 16:47 ` KY Srinivasan
2017-04-10 14:44 ` Vitaly Kuznetsov
2017-04-10 17:34 ` Jork Loeser
2017-04-10 22:03 ` KY Srinivasan
2017-04-07 11:27 ` [PATCH 7/7] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others() Vitaly Kuznetsov
2017-04-07 14:38 ` Steven Rostedt
2017-04-08 14:57 ` [PATCH 0/7] Hyper-V: praravirtualized remote TLB flushing and hypercall improvements KY Srinivasan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a87oqiu9.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=Jork.Loeser@microsoft.com \
--cc=devel@linuxdriverproject.org \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=sthemmin@microsoft.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.