Re: [Xen-devel] [PATCH v5 0/9] Improve non-"safe" MSR access failure handling

[Boris Ostrovsky]

On 04/02/2016 10:01 AM, Andy Lutomirski wrote:


Andy Lutomirski (9):
   x86/head: Pass a real pt_regs and trapnr to early_fixup_exception
   x86/head: Move the early NMI fixup into C
   x86/head: Move early exception panic code into early_fixup_exception
   x86/traps: Enable all exception handler callbacks early
   x86/paravirt: Add _safe to the read_msr and write_msr PV hooks
   x86/msr: Carry on after a non-"safe" MSR access fails
   x86/paravirt: Add paravirt_{read,write}_msr
   x86/paravirt: Make "unsafe" MSR accesses unsafe even if PARAVIRT=y
   x86/msr: Set the return value to zero when native_rdmsr_safe fails


With Xen (on top of eb1af3b):

Tested-by: Boris Ostrovsky 

-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 0/9] Improve non-"safe" MSR access failure handling

[Borislav Petkov]

On Sat, Apr 02, 2016 at 07:01:31AM -0700, Andy Lutomirski wrote:
> There are two parts here:
> 
> * FIRST PART: EARLY EXCEPTIONS *
> 
> The first few patches move some early panic code into C, add pt_regs
> to early exception handling, and make fancy exception handlers work early.
> 
> * SECOND PART: MSRs *
> 
> Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently
> turns all rdmsr and wrmsr operations into the safe variants without
> any checks that the operations actually succeed.


...

FWIW:

Reviewed-by: Borislav Petkov 

Definitely a step in the right direction, regardless of how we're going
to be doing early_printk(), which is a tangential topic. This pile could
be taken for a spin in tip.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 0/9] Improve non-"safe" MSR access failure handling

[Linus Torvalds]

On Sat, Apr 2, 2016 at 10:13 AM, Andy Lutomirski  wrote:
>
> I also tried a bad wrmsrl at a couple early points.  Very very early
> it just works with not warning.  A little later and it prints the
> warning.

Ok, that sounds like the correct behavior - I'm sure the very very
early ones "warned" too, it just got dropped on the floor due to being
before the printing/logging was up and running.

And even then, it's obviously much better than having machines
mysteriously just reboot.

Thanks,
 Linus

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 0/9] Improve non-"safe" MSR access failure handling

[Andy Lutomirski]

On Sat, Apr 2, 2016 at 7:24 AM, Linus Torvalds
 wrote:
> This patch series looks much nicer than the last one. I assume you
> tested that the early-trap handling actually worked too? I only looked
> at the patches..
>
> Ack to it all,

I injected some BUGs in various places on 32-bit an 64-bit and it
seemed to do the right thing.  Depending on how early they were, I
either got a clean hang or I got a printout, and whether it displayed
anything didn't seem to change with and without the patches.  I think
that early_printk doesn't work from the very very beginning.

I also tried a bad wrmsrl at a couple early points.  Very very early
it just works with not warning.  A little later and it prints the
warning.

--Andy

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 0/9] Improve non-"safe" MSR access failure handling

[Linus Torvalds]

This patch series looks much nicer than the last one. I assume you
tested that the early-trap handling actually worked too? I only looked
at the patches..

Ack to it all,

   Linus

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel