Re: Hyper-V protection fault trap on i386 with 5.9

[Mike Larkin]

On Mon, Jul 25, 2016 at 10:59:45AM +0200, Franco Fichtner wrote:
> 
> > On 22 Jul 2016, at 7:58 PM, Mike Larkin  wrote:
> > 
> > What is your Hyper-V server host environment? Server 2012 R2? And I
> > need a full dmesg from when this worked, please.
> 
> It's a Windows Server 2012 Datacenter Hyper-V failover cluster, controlled
> by System Center 2012 Virtual Machine Manager.  All of it is up-to-date as
> of July 2016.
> 
> Will a dmesg of a patched (bootable) 5.9 suffice or should it be the 5.7 one?
> 
> 
> Cheers,
> Franco
> 

Server 2012 or Server 2012 R2?

I just tested both Server 2012 R2 and Windows 10 client Hyper-V on -current,
and both worked without any problem (OpenBSD-current i386).

-ml 

Re: Hyper-V protection fault trap on i386 with 5.9

[Franco Fichtner]

> On 22 Jul 2016, at 7:58 PM, Mike Larkin  wrote:
> 
> What is your Hyper-V server host environment? Server 2012 R2? And I
> need a full dmesg from when this worked, please.

It's a Windows Server 2012 Datacenter Hyper-V failover cluster, controlled
by System Center 2012 Virtual Machine Manager.  All of it is up-to-date as
of July 2016.

Will a dmesg of a patched (bootable) 5.9 suffice or should it be the 5.7 one?


Cheers,
Franco

Re: Hyper-V protection fault trap on i386 with 5.9

[Mike Larkin]

On Fri, Jul 22, 2016 at 03:26:01PM +0200, Franco Fichtner wrote:
> Hi,
> 
> With a client we're running into the following boot panic
> since upgrading from 5.7 to 5.9 on a specific Hyper-V guest:
> 
> cpu0: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz ("GenuineIntel" 686-class) 1.65 GHz
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
> LUSH,MMX,FXSR,SSE,SSE2,SS,HTT,NXE,LONG,SSE3,SSSE3,CX16,SSE5.1,XSAVE,HV,LAHF
> [...]
> kernel: protection fault trap, code=0
> Stopped at cpu_paenable+0x20: movl %edi,%cr3
> 
> This happens consistently, but we have other clients that
> run Hyper-V without a problem on 5.9 now.
> 
> Looking for a clue I dug through the commits and found that
> reviving pmap_bootstrap_pae() in April 2015 caused this, and
> reverting boots said Hyper-V guest just fine.
> 
> Hyper-V is on the latest version and we could not find a
> reason why said guest / host pair behaves that way.
> 
> I have two questions:
> 
> (1) Since NX/PAE is pretty much standard on all hardware from
> the last +15 years and is now used to enforce W^X, are there
> going to be problems *not* running that code either now or in
> the future?
> 
> (2) Could this be something to be fixed in the i386 assembler
> code in cpu_paenable?
> 
> It's difficult to get dumps / screen caps from the system or
> run commands in ddb, but if there's interest I will try to
> provide the requested info.
> 
> 
> Cheers,
> Franco

Certainly odd. I'll try to reproduce this (since I was the one who
brought PAE/NX back into the i386 picture last year). It should work
fine (this is the first report I've seen about crashing there).

What is your Hyper-V server host environment? Server 2012 R2? And I
need a full dmesg from when this worked, please.

It's also possible this is a Hyper-V bug. We've seen those as well
and had to work around them also.

-ml

Hyper-V protection fault trap on i386 with 5.9

[Franco Fichtner]

Hi,

With a client we're running into the following boot panic
since upgrading from 5.7 to 5.9 on a specific Hyper-V guest:

cpu0: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz ("GenuineIntel" 686-class) 1.65 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
LUSH,MMX,FXSR,SSE,SSE2,SS,HTT,NXE,LONG,SSE3,SSSE3,CX16,SSE5.1,XSAVE,HV,LAHF
[...]
kernel: protection fault trap, code=0
Stopped at cpu_paenable+0x20: movl %edi,%cr3

This happens consistently, but we have other clients that
run Hyper-V without a problem on 5.9 now.

Looking for a clue I dug through the commits and found that
reviving pmap_bootstrap_pae() in April 2015 caused this, and
reverting boots said Hyper-V guest just fine.

Hyper-V is on the latest version and we could not find a
reason why said guest / host pair behaves that way.

I have two questions:

(1) Since NX/PAE is pretty much standard on all hardware from
the last +15 years and is now used to enforce W^X, are there
going to be problems *not* running that code either now or in
the future?

(2) Could this be something to be fixed in the i386 assembler
code in cpu_paenable?

It's difficult to get dumps / screen caps from the system or
run commands in ddb, but if there's interest I will try to
provide the requested info.


Cheers,
Franco