[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops
- To: Paolo Bonzini <pbonzini@xxxxxxxxxx>, Andy Lutomirski <luto@xxxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>
- From: Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>
- Date: Thu, 17 Sep 2015 08:31:09 -0700
- Cc: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>, KVM list <kvm@xxxxxxxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, X86 ML <x86@xxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, xen-devel <Xen-devel@xxxxxxxxxxxxx>, Andy Lutomirski <luto@xxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 17 Sep 2015 15:31:21 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On 9/17/2015 8:29 AM, Paolo Bonzini wrote:
On 17/09/2015 17:27, Arjan van de Ven wrote:
( We should double check that rdmsr()/wrmsr() results are never left
uninitialized, but are set to zero or so, for cases where the
return code is not
checked. )
It sure looks like native_read_msr_safe doesn't clear the output if
the rdmsr fails.
I'd suggest to return some poison not just 0...
What about 0 + WARN?
why 0?
0xdeadbeef or any other pattern (even 0x3636363636) makes more sense (of course
also WARN... but most folks don't read dmesg for WARNs)
(it's the same thing we do for list or slab poison stuff)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
