On 22/08/20 18:42, Andy Lutomirski wrote:
> On VMX, when a VM exits, the VM's
> value of MSR_TSC_AUX is live, and we can take an NMI, MCE, or
> abominable new #SX, #VE, #VC, etc on the next instruction boundary.
> And unless we use the atomic MSR switch mechanism, the result is that
> we're going
On Fri, Aug 21, 2020 at 3:07 AM Paolo Bonzini wrote:
>
> On 21/08/20 11:48, Borislav Petkov wrote:
> >> It's not like we grab MSRs every day. The user-return notifier restores
> >> 6 MSRs (7 on very old processors). The last two that were added were
> >> MSR_TSC_AUX itself in 2009 (!) and
On Fri, Aug 21, 2020 at 12:55:53PM -0700, h...@zytor.com wrote:
> It is hardly going to be a performance difference for paranoid entry,
> which is hopefully rare enough that it falls into the noise.
Try perf some day ;-)
But yeah, given the utter trainwreck that NMIs are anyway, this is all
not
On August 21, 2020 2:28:32 AM PDT, Thomas Gleixner wrote:
>On Fri, Aug 21 2020 at 10:09, Paolo Bonzini wrote:
>> On 21/08/20 09:47, Borislav Petkov wrote:
>>> On Thu, Aug 20, 2020 at 07:50:50PM -0700, Sean Christopherson wrote:
+ * Disallow RDPID if KVM is enabled as it may consume a
Hi Sean,
I love your patch! Yet something to improve:
[auto build test ERROR on tip/auto-latest]
[also build test ERROR on v5.9-rc1 next-20200821]
[cannot apply to tip/x86/asm luto/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
On 21/08/20 11:48, Borislav Petkov wrote:
>> It's not like we grab MSRs every day. The user-return notifier restores
>> 6 MSRs (7 on very old processors). The last two that were added were
>> MSR_TSC_AUX itself in 2009 (!) and MSR_IA32_TSX_CTRL last year.
> What about "If it is a shared
On Fri, Aug 21, 2020 at 11:44:33AM +0200, Paolo Bonzini wrote:
> It's not like we grab MSRs every day. The user-return notifier restores
> 6 MSRs (7 on very old processors). The last two that were added were
> MSR_TSC_AUX itself in 2009 (!) and MSR_IA32_TSX_CTRL last year.
What about "If it is
On 21/08/20 11:22, Borislav Petkov wrote:
>> Hence the assumption that KVM makes (and has made ever since TSC_AUX was
>> introduced.
> And *this* is the problem. KVM can't just be grabbing MSRs and claiming
> them because it started using them first. You guys need to stop this. If
> it is a shared
On 21/08/20 11:28, Thomas Gleixner wrote:
> We all know that MSRs are slow, but as a general rule I have to make it
> entirely clear that the kernel has precedence over KVM.
I totally agree. I just don't think that it matters _in this case_,
because the kernel hardly has any reason to use
On Fri, Aug 21 2020 at 10:09, Paolo Bonzini wrote:
> On 21/08/20 09:47, Borislav Petkov wrote:
>> On Thu, Aug 20, 2020 at 07:50:50PM -0700, Sean Christopherson wrote:
>>> +* Disallow RDPID if KVM is enabled as it may consume a guest's TSC_AUX
>>> +* if an NMI arrives in KVM's run loop.
On Fri, Aug 21, 2020 at 11:05:24AM +0200, Paolo Bonzini wrote:
> ... RDTSCP is used as an ordered rdtsc but it discards the TSC_AUX
> value.
... and now because KVM is using it, the kernel can forget using
TSC_AUX. Are you kidding me?!
> Hence the assumption that KVM makes (and has made ever
On 21/08/20 10:16, Borislav Petkov wrote:
> On Fri, Aug 21, 2020 at 10:09:01AM +0200, Paolo Bonzini wrote:
>> One more MSR *is* a big deal: KVM's vmentry+vmexit cost is around 1000
>> cycles, adding 100 clock cycles for 2 WRMSRs is a 10% increase.
>
> The kernel uses TSC_AUX so we can't reserve
Hi Sean,
I love your patch! Yet something to improve:
[auto build test ERROR on tip/auto-latest]
[also build test ERROR on v5.9-rc1 next-20200821]
[cannot apply to tip/x86/asm luto/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
On Fri, Aug 21, 2020 at 10:09:01AM +0200, Paolo Bonzini wrote:
> One more MSR *is* a big deal: KVM's vmentry+vmexit cost is around 1000
> cycles, adding 100 clock cycles for 2 WRMSRs is a 10% increase.
The kernel uses TSC_AUX so we can't reserve it to KVM either.
--
Regards/Gruss,
Boris.
On 21/08/20 09:47, Borislav Petkov wrote:
> On Thu, Aug 20, 2020 at 07:50:50PM -0700, Sean Christopherson wrote:
>> + * Disallow RDPID if KVM is enabled as it may consume a guest's TSC_AUX
>> + * if an NMI arrives in KVM's run loop. KVM loads guest's TSC_AUX on
>> + * VM-Enter and may
On Thu, Aug 20, 2020 at 07:50:50PM -0700, Sean Christopherson wrote:
> + * Disallow RDPID if KVM is enabled as it may consume a guest's TSC_AUX
> + * if an NMI arrives in KVM's run loop. KVM loads guest's TSC_AUX on
> + * VM-Enter and may not restore the host's value until the CPU
On Fri, Aug 21, 2020 at 09:24:14AM +0200, pet...@infradead.org wrote:
> With distro configs that's going to be a guaranteed no_rdpid. Also with
> a grand total of 0 performance numbers that RDPID is even worth it, I'd
> suggest to just unconditionally remove that thing. Simpler code
> all-around.
On Thu, Aug 20, 2020 at 07:50:50PM -0700, Sean Christopherson wrote:
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index 70dea93378162..fd915c46297c5 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -842,8 +842,13 @@
Don't use RDPID in the paranoid entry flow if KVM is enabled as doing so
can consume a KVM guest's MSR_TSC_AUX value if an NMI arrives in KVM's
run loop.
As a performance optimization, KVM loads the guest's TSC_AUX when a CPU
first enters its run loop, and on AMD's SVM doesn't restore the host's
19 matches
Mail list logo
