Error adding tunnel to mgre interface
Hi, I am trying to add a tunnel to an mgre interface. I can't get past the following error. $doas ifconfig mgre0 destroy $doas ifconfig mgre0 create $doas ifconfig mgre0 tunnel 192.0.2.1 192.0.2.1 ifconfig: SIOCSLIFPHYADDR: Invalid argument $ $ifconfig mgre mgre0: flags=8800 mtu 1476 index 9 priority 0 llprio 3 encap: vnetid none groups: mgre tunnel: (unset) ttl 64 nodf $ This is on a default install with patches up to and including 014. OpenBSD 6.3 GENERIC.MP#7 amd64 If anyone has had success setting up an mgre interface then I would appreciate a little advice. Regards Joe
014_amdlfence.patch breaks OpenBSD VMs on AMD systems
After installing the 014_amdlfence patch released yesterday for 6.3, my
OpenBSD VM crashes on boot. It's running under KVM on a Linux box
(Ubuntu 18.04 w/ kernel 4.15) on an AMD Ryzen 7 1700 (microcode 0x8001137).
I suppose this would also happen on vmm(4) and bhyve, however I don't
have any such AMD hosts available for testing.
It occurs both using libvirt's "EPYC" CPU model and using
"host-passthrough" (i.e. no virtual CPU model), but the "core2duo" CPU
model works fine.
I guess not many people are running OpenBSD as a VM, and even less on
AMD hardware. But still, a syspatch leaving the system unable to boot is
probably not a good thing. :)
Kernel output:
>> OpenBSD/amd64 BOOT 3.34
boot>
booting hd0a:/bsd: 8616075+2454544+262168+0+671744
[646904+98+712056+493074]=0xd39630
entry point at 0x1000158
[ using 1852976 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2018 OpenBSD. All rights reserved.
https://www.OpenBSD.org
OpenBSD 6.3 (GENERIC.MP) #7: Sun Jul 29 11:43:12 CEST 2018
r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2130546688 (2031MB)
avail mem = 2058960896 (1963MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6880 (10 entries)
bios0: vendor SeaBIOS version "1.10.2-1ubuntu1" date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: sleep states S5
acpi0: tables DSDT FACP APIC
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 7 1700 Eight-Core Processor, 2994.73 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
kernel: protection fault trap, code=0
Stopped at identifycpu+0x7ad: rdmsr
ddb{0}> trace
identifycpu(81a99ff0,80039400,81d40a58,8000210b9000
,81d40a60,12ad28e092a02002) at identifycpu+0x7ad
cpu_attach(80023100,81d40a58,81a97040,80039400,
80039424,12ad28e092a02002) at cpu_attach+0x326
config_attach(0,8001c744,8001c718,8001c744,81d4
0a38,813ce5d0) at config_attach+0x1d8
acpimadt_attach(80020400,81d40b60,81aa84d0,8003
9b80,80039ba4,12ad28e092a02002) at acpimadt_attach+0x3be
config_attach(81d40b60,80020400,80020470,800204
60,8001c700,81683350) at config_attach+0x1d8
acpi_attach(80023180,81d40c50,81abf0d8,80020400
,80020424,12ad28e092a02002) at acpi_attach+0x5c1
config_attach(8000210b7884,80023180,50,118,8000210b78b0,fff
f81256180) at config_attach+0x1d8
bios_attach(80023100,81d40d88,81aa2188,80023180
,800231a4,12ad28e092a02002) at bios_attach+0x636
config_attach(81d40d88,80023100,81ab0bb0,800231
00,80023124,81456d90) at config_attach+0x1d8
mainbus_attach(0,0,12ad28e092a02002,81d40db0,81d40e20,30001
0) at mainbus_attach+0x71
config_attach(0,819a78b4,81ac8fd2,81d40e78,b28,0)
at co
nfig_attach+0x1d8
config_rootfound(0,0,0,0,81d3a008,12ad28e092a02002) at
config_rootfound
+0xd3
cpu_configure(0,0,8141440b,81d40ef0,0,0) at
cpu_configure+0x1b
main(0,0,0,12ad28e092a02002,814eff28,81d40f20) at main+0x4a8
end trace frame: 0x0, count: -14
ddb{0}> ps
PID TID PPIDUID S FLAGS WAIT COMMAND
*0 0 -1 0 7 0x10200swapper
Re: 014_amdlfence.patch breaks OpenBSD VMs on AMD systems
On Wed, Aug 01, 2018 at 03:46:25PM +0200, Elmer Skjødt Henriksen wrote:
> After installing the 014_amdlfence patch released yesterday for 6.3, my
> OpenBSD VM crashes on boot. It's running under KVM on a Linux box (Ubuntu
> 18.04 w/ kernel 4.15) on an AMD Ryzen 7 1700 (microcode 0x8001137).
> I suppose this would also happen on vmm(4) and bhyve, however I don't have
> any such AMD hosts available for testing.
Hi Elmer,
This was tested in vmm(4), which does work, unfortunately there was not
extensive testing by in other virtualization software. The MSR that is
being set here is only mentioned in AMDs whitepaper and I had no reason
to believe any special consideration was needed for guest VMs on AMD
processors.
> It occurs both using libvirt's "EPYC" CPU model and using "host-passthrough"
> (i.e. no virtual CPU model), but the "core2duo" CPU model works fine.
>
> I guess not many people are running OpenBSD as a VM, and even less on AMD
> hardware. But still, a syspatch leaving the system unable to boot is
> probably not a good thing. :)
>
Even so, I would like to apologize. This situation is unfortunate, and
I'll try to work with other developers to find the best way forward.
But, I regret I am only but an amateur magician.
-Bryan.
> Kernel output:
> >> OpenBSD/amd64 BOOT 3.34
> boot>
> booting hd0a:/bsd: 8616075+2454544+262168+0+671744
> [646904+98+712056+493074]=0xd39630
> entry point at 0x1000158
> [ using 1852976 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California. All rights reserved.
> Copyright (c) 1995-2018 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
>
> OpenBSD 6.3 (GENERIC.MP) #7: Sun Jul 29 11:43:12 CEST 2018
>
> r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 2130546688 (2031MB)
> avail mem = 2058960896 (1963MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6880 (10 entries)
> bios0: vendor SeaBIOS version "1.10.2-1ubuntu1" date 04/01/2014
> bios0: QEMU Standard PC (i440FX + PIIX, 1996)
> acpi0 at bios0: rev 0
> acpi0: sleep states S5
> acpi0: tables DSDT FACP APIC
> acpi0: wakeup devices
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Ryzen 7 1700 Eight-Core Processor, 2994.73 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
> 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 cache
> cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> kernel: protection fault trap, code=0
> Stopped at identifycpu+0x7ad: rdmsr
> ddb{0}> trace
> identifycpu(81a99ff0,80039400,81d40a58,8000210b9000
> ,81d40a60,12ad28e092a02002) at identifycpu+0x7ad
> cpu_attach(80023100,81d40a58,81a97040,80039400,
> 80039424,12ad28e092a02002) at cpu_attach+0x326
> config_attach(0,8001c744,8001c718,8001c744,81d4
> 0a38,813ce5d0) at config_attach+0x1d8
> acpimadt_attach(80020400,81d40b60,81aa84d0,8003
> 9b80,80039ba4,12ad28e092a02002) at acpimadt_attach+0x3be
> config_attach(81d40b60,80020400,80020470,800204
> 60,8001c700,81683350) at config_attach+0x1d8
> acpi_attach(80023180,81d40c50,81abf0d8,80020400
> ,80020424,12ad28e092a02002) at acpi_attach+0x5c1
> config_attach(8000210b7884,80023180,50,118,8000210b78b0,fff
> f81256180) at config_attach+0x1d8
> bios_attach(80023100,81d40d88,81aa2188,80023180
> ,800231a4,12ad28e092a02002) at bios_attach+0x636
> config_attach(81d40d88,80023100,81ab0bb0,800231
> 00,80023124,81456d90) at config_attach+0x1d8
> mainbus_attach(0,0,12ad28e092a02002,81d40db0,81d40e20,30001
> 0) at mainbus_attach+0x71
> config_attach(0,819a78b4,81ac8fd2,81d40e78,b28,0) at
> co
> nfig_attach+0x1d8
> config_rootfound(0,0,0,0,81d3a008,12ad28e092a02002) at
> config_rootfound
> +0xd3
> cpu_configure(0,0,8141440b,81d40ef0,0,0) at
> cpu_configure+0x1b
> main(0,0,0,12ad28e092a02002,814eff28,81d40f20) at main+0x4a8
> end trace frame: 0x0, count: -14
> ddb{0}> ps
>PID TID PPIDUID
Re: 014_amdlfence.patch breaks OpenBSD VMs on AMD systems
On Wed, Aug 01, 2018 at 11:27:26AM -0400, Bryan Steele wrote:
> On Wed, Aug 01, 2018 at 03:46:25PM +0200, Elmer Skjødt Henriksen wrote:
> > After installing the 014_amdlfence patch released yesterday for 6.3, my
> > OpenBSD VM crashes on boot. It's running under KVM on a Linux box (Ubuntu
> > 18.04 w/ kernel 4.15) on an AMD Ryzen 7 1700 (microcode 0x8001137).
> > I suppose this would also happen on vmm(4) and bhyve, however I don't have
> > any such AMD hosts available for testing.
>
> Hi Elmer,
>
> This was tested in vmm(4), which does work, unfortunately there was not
> extensive testing by in other virtualization software. The MSR that is
> being set here is only mentioned in AMDs whitepaper and I had no reason
> to believe any special consideration was needed for guest VMs on AMD
> processors.
>
> > It occurs both using libvirt's "EPYC" CPU model and using "host-passthrough"
> > (i.e. no virtual CPU model), but the "core2duo" CPU model works fine.
> >
> > I guess not many people are running OpenBSD as a VM, and even less on AMD
> > hardware. But still, a syspatch leaving the system unable to boot is
> > probably not a good thing. :)
> >
>
> Even so, I would like to apologize. This situation is unfortunate, and
> I'll try to work with other developers to find the best way forward.
> But, I regret I am only but an amateur magician.
>
> -Bryan.
Actually, it looks like this is at least partially a KVM/QEMU bug. In
the meantime I guess the solution would be to do as you suggested and
set a different CPU model for now until Linux distros include a fix for
this.
https://lkml.org/lkml/2018/2/21/1202
Afterwards, on the OpenBSD side, it looks like one small change may be
required in addition..
-Bryan.
Index: sys/arch/amd64/amd64/identcpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
retrieving revision 1.95.2.2
diff -u -p -u -r1.95.2.2 identcpu.c
--- sys/arch/amd64/amd64/identcpu.c 30 Jul 2018 14:45:05 - 1.95.2.2
+++ sys/arch/amd64/amd64/identcpu.c 1 Aug 2018 16:09:50 -
@@ -650,8 +650,10 @@ identifycpu(struct cpu_info *ci)
msr = rdmsr(MSR_DE_CFG);
#define DE_CFG_SERIALIZE_LFENCE(1 << 1)
- msr |= DE_CFG_SERIALIZE_LFENCE;
- wrmsr(MSR_DE_CFG, msr);
+ if ((msr & DE_CFG_SERIALIZE_LFENCE) == 0) {
+ msr |= DE_CFG_SERIALIZE_LFENCE;
+ wrmsr(MSR_DE_CFG, msr);
+ }
}
}
nmap on routed ip4 networks, openbsd/pf or package/port issue?
Hi. I very rarely post on these lists, so please go easy on me. Not sure on what list to post, since I don't know what causes the issue, so I thought I would start here and maybe get directed elsewhere. So I set up a new 6.3 with the sole purpose of nmapping, since my older OpenBSDs is coremapping on me with nmap. A very clean setup; 2 interfaces: em0: 192.168.1.200/24 em1: 10.10.10.200/26 mygate: 192.168.1.1 route: 10/8 -> 10.10.10.193 resolv.conf: 8.8.8.8 pf.conf: set skip on lo block return pass sysctl is default out of the box except for machdep.allowaperture=2 nmap is from 6.3 packages: nmap-7.60p0 Can ping and communicate everywhere essential, so network on both ifs seems fine. On to the problem, I scan my local LAN with the following: nmap -Pn -A -v -v --send-eth -e em0 -stylesheet somestylesheet -oA /tmp/nmapout 192.168.1.0/24 This works fine, every time i try. Takes about an hour. However, when I try it on a remote routed net like so: nmap -Pn -A -v -v --send-eth -e em1 -stylesheet somestylesheet -oA /tmp/nmapout 10.20.30.192/26 nmap stops doing anything after a minute or so, it goes to 0% cpu and stays there. I waited at least 24 hours without any sign of life. top tells me nmap is WAIT/bpf after those first couple of minutes. I am not sure what that means exactly, but I figured maybe something with pf, so I disabled pf alltogether and tried again, with the same result. For some reason, I also tried it again against 10.20.30.193-254, but no luck. Still stops after a minute or two and just does nothing. Worth mentioning is it starts off fine, giving me loads of information about open ports and completed SYN stealth scans against hosts. I am well aware that this might not be perfectly suited for misc, but I recall having several issues in the past with the combination OpenBSD/pf/nmap, so I thought I would give it a shot here first. "Hardware" under this OpenBSD is VMWare Workstation Pro 14.1 on Windows 10, where the 2 vm-nics are bridged to 2 VLAN configured virtual Intel (I219-LM) NICs on my Windows host. I don't think that is what's causing the issue I am having, but thought I should mention it. "dmesg" output is at the bottom. Best Regards, Henrik Engmark My food poops of your food ### dmesg ### OpenBSD 6.3 (GENERIC.MP) #107: Sat Mar 24 14:21:59 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17162960896 (16367MB) avail mem = 16635740160 (15865MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0010 (248 entries) bios0: vendor Phoenix Technologies LTD version "6.00" date 05/19/2017 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) S16F(S3) S17F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) S1F0(S3) PE50(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz, 2592.13 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache acpitimer0: recalibrated TSC frequency 2591813105 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 65MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz, 2591.88 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz, 2591.94 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,ARAT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz, 2591.88 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,AP
Re: 014_amdlfence.patch breaks OpenBSD VMs on AMD systems
On Wed, Aug 01, 2018 at 12:14:59PM -0400, Bryan Steele wrote:
> On Wed, Aug 01, 2018 at 11:27:26AM -0400, Bryan Steele wrote:
> > On Wed, Aug 01, 2018 at 03:46:25PM +0200, Elmer Skjødt Henriksen wrote:
> > > After installing the 014_amdlfence patch released yesterday for 6.3, my
> > > OpenBSD VM crashes on boot. It's running under KVM on a Linux box (Ubuntu
> > > 18.04 w/ kernel 4.15) on an AMD Ryzen 7 1700 (microcode 0x8001137).
> > > I suppose this would also happen on vmm(4) and bhyve, however I don't have
> > > any such AMD hosts available for testing.
> >
> > Hi Elmer,
> >
> > This was tested in vmm(4), which does work, unfortunately there was not
> > extensive testing by in other virtualization software. The MSR that is
> > being set here is only mentioned in AMDs whitepaper and I had no reason
> > to believe any special consideration was needed for guest VMs on AMD
> > processors.
> >
> > > It occurs both using libvirt's "EPYC" CPU model and using
> > > "host-passthrough"
> > > (i.e. no virtual CPU model), but the "core2duo" CPU model works fine.
> > >
> > > I guess not many people are running OpenBSD as a VM, and even less on AMD
> > > hardware. But still, a syspatch leaving the system unable to boot is
> > > probably not a good thing. :)
> > >
> >
> > Even so, I would like to apologize. This situation is unfortunate, and
> > I'll try to work with other developers to find the best way forward.
> > But, I regret I am only but an amateur magician.
> >
> > -Bryan.
>
> Actually, it looks like this is at least partially a KVM/QEMU bug. In
> the meantime I guess the solution would be to do as you suggested and
> set a different CPU model for now until Linux distros include a fix for
> this.
>
> https://lkml.org/lkml/2018/2/21/1202
>
> Afterwards, on the OpenBSD side, it looks like one small change may be
> required in addition..
>
> -Bryan.
>
> Index: sys/arch/amd64/amd64/identcpu.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
> retrieving revision 1.95.2.2
> diff -u -p -u -r1.95.2.2 identcpu.c
> --- sys/arch/amd64/amd64/identcpu.c 30 Jul 2018 14:45:05 - 1.95.2.2
> +++ sys/arch/amd64/amd64/identcpu.c 1 Aug 2018 16:09:50 -
> @@ -650,8 +650,10 @@ identifycpu(struct cpu_info *ci)
>
> msr = rdmsr(MSR_DE_CFG);
> #define DE_CFG_SERIALIZE_LFENCE (1 << 1)
> - msr |= DE_CFG_SERIALIZE_LFENCE;
> - wrmsr(MSR_DE_CFG, msr);
> + if ((msr & DE_CFG_SERIALIZE_LFENCE) == 0) {
> + msr |= DE_CFG_SERIALIZE_LFENCE;
> + wrmsr(MSR_DE_CFG, msr);
> + }
> }
> }
>
>
As far as I can tell, nowhere does AMD claim this is a RO MSR. Thus, KVM might
not be doing the right thing here by #GPing the guest on write. It is possible
though, that it is described this way in some document I don't have access to.
The diff you propose above is safe however, so if you want to make that change,
ok mlarkin.
I will test the diff on real hardware today. I stand by my belief that KVM is
doing
something in a nonstandard way here, but I'll check real hardware to make sure.
-ml
Re: nmap on routed ip4 networks, openbsd/pf or package/port issue?
On 08-01 15:08, Henrik Engmark wrote: > So I set up a new 6.3 with the sole purpose of nmapping, since my older > OpenBSDs is coremapping on me with nmap. >[] > On to the problem, I scan my local LAN with the following: > nmap -Pn -A -v -v --send-eth -e em0 -stylesheet somestylesheet -oA > /tmp/nmapout 192.168.1.0/24 > This works fine, every time i try. Takes about an hour. However, when I try > it on a remote routed net like so: > nmap -Pn -A -v -v --send-eth -e em1 -stylesheet somestylesheet -oA > /tmp/nmapout 10.20.30.192/26 > > nmap stops doing anything after a minute or so, it goes to 0% cpu and stays > there. I waited at least 24 hours without any sign of life. > top tells me nmap is WAIT/bpf after those first couple of minutes. I am not > sure what that means exactly, but I figured maybe something with pf, so I > disabled pf alltogether and tried again, with the same result. I am curious what you learn as I have seen similar behavior. I've been nmapping a printer on my local network, trying different things, and nmap freezes for me after a short or long time. Strangely though, it seems to ~ "unfreeze" if I start another nmap instance, probing the same address, in a separate terminal window. Sometimes I have to kill and restart that other instance as it freezes too, but this workaround has allowed me to continue at least. I am on 6.3 stable with latest syspatch.
Re: nmap on routed ip4 networks, openbsd/pf or package/port issue?
On 08-01 10:54, Luke A. Call wrote: > On 08-01 15:08, Henrik Engmark wrote: > > So I set up a new 6.3 with the sole purpose of nmapping, since my older > > OpenBSDs is coremapping on me with nmap. > >[] > > On to the problem, I scan my local LAN with the following: > > nmap -Pn -A -v -v --send-eth -e em0 -stylesheet somestylesheet -oA > > /tmp/nmapout 192.168.1.0/24 > > This works fine, every time i try. Takes about an hour. However, when I try > > it on a remote routed net like so: > > nmap -Pn -A -v -v --send-eth -e em1 -stylesheet somestylesheet -oA > > /tmp/nmapout 10.20.30.192/26 > > > > nmap stops doing anything after a minute or so, it goes to 0% cpu and stays > > there. I waited at least 24 hours without any sign of life. > > top tells me nmap is WAIT/bpf after those first couple of minutes. I am not > > sure what that means exactly, but I figured maybe something with pf, so I > > disabled pf alltogether and tried again, with the same result. > > I am curious what you learn as I have seen similar behavior. I've been > nmapping a printer on my local network, trying different things, and nmap > freezes for me after a short or long time. > > Strangely though, it seems to ~ "unfreeze" if I start another nmap > instance, probing the same address, in a separate terminal window. > Sometimes I have to kill and restart that other instance as it > freezes too, but this workaround has allowed me to continue at least. > > I am on 6.3 stable with latest syspatch. Also curiously, the 2nd nmap running, like the first instance it is intended to "unfreeze", also uses 90+% of a CPU (until it also freezes), even though I passed the "-T2" parameter to slow it down.
Re: 014_amdlfence.patch breaks OpenBSD VMs on AMD systems
On Wed, Aug 01, 2018 at 12:14:59PM -0400, Bryan Steele wrote:
> On Wed, Aug 01, 2018 at 11:27:26AM -0400, Bryan Steele wrote:
> > On Wed, Aug 01, 2018 at 03:46:25PM +0200, Elmer Skjødt Henriksen wrote:
> > > After installing the 014_amdlfence patch released yesterday for 6.3, my
> > > OpenBSD VM crashes on boot. It's running under KVM on a Linux box (Ubuntu
> > > 18.04 w/ kernel 4.15) on an AMD Ryzen 7 1700 (microcode 0x8001137).
> > > I suppose this would also happen on vmm(4) and bhyve, however I don't have
> > > any such AMD hosts available for testing.
> >
> > Hi Elmer,
> >
> > This was tested in vmm(4), which does work, unfortunately there was not
> > extensive testing by in other virtualization software. The MSR that is
> > being set here is only mentioned in AMDs whitepaper and I had no reason
> > to believe any special consideration was needed for guest VMs on AMD
> > processors.
> >
> > > It occurs both using libvirt's "EPYC" CPU model and using
> > > "host-passthrough"
> > > (i.e. no virtual CPU model), but the "core2duo" CPU model works fine.
> > >
> > > I guess not many people are running OpenBSD as a VM, and even less on AMD
> > > hardware. But still, a syspatch leaving the system unable to boot is
> > > probably not a good thing. :)
> > >
> >
> > Even so, I would like to apologize. This situation is unfortunate, and
> > I'll try to work with other developers to find the best way forward.
> > But, I regret I am only but an amateur magician.
> >
> > -Bryan.
>
> Actually, it looks like this is at least partially a KVM/QEMU bug. In
> the meantime I guess the solution would be to do as you suggested and
> set a different CPU model for now until Linux distros include a fix for
> this.
>
> https://lkml.org/lkml/2018/2/21/1202
>
> Afterwards, on the OpenBSD side, it looks like one small change may be
> required in addition..
>
> -Bryan.
>
> Index: sys/arch/amd64/amd64/identcpu.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
> retrieving revision 1.95.2.2
> diff -u -p -u -r1.95.2.2 identcpu.c
> --- sys/arch/amd64/amd64/identcpu.c 30 Jul 2018 14:45:05 - 1.95.2.2
> +++ sys/arch/amd64/amd64/identcpu.c 1 Aug 2018 16:09:50 -
> @@ -650,8 +650,10 @@ identifycpu(struct cpu_info *ci)
>
> msr = rdmsr(MSR_DE_CFG);
> #define DE_CFG_SERIALIZE_LFENCE (1 << 1)
> - msr |= DE_CFG_SERIALIZE_LFENCE;
> - wrmsr(MSR_DE_CFG, msr);
> + if ((msr & DE_CFG_SERIALIZE_LFENCE) == 0) {
> + msr |= DE_CFG_SERIALIZE_LFENCE;
> + wrmsr(MSR_DE_CFG, msr);
> + }
> }
> }
>
>
As expected, -current works properly on real AMD hardware. So my assumption
about KVM doing something odd seems to be correct.
The issue should be reported upstream to the KVM folks. But if the diff above
also fixes the issue (I didn't test because I cannot reproduce it), ok mlarkin.
-ml
Re: 014_amdlfence.patch breaks OpenBSD VMs on AMD systems
On Wed, Aug 01, 2018 at 01:07:33PM -0700, Mike Larkin wrote:
> On Wed, Aug 01, 2018 at 12:14:59PM -0400, Bryan Steele wrote:
> > On Wed, Aug 01, 2018 at 11:27:26AM -0400, Bryan Steele wrote:
> > > On Wed, Aug 01, 2018 at 03:46:25PM +0200, Elmer Skjødt Henriksen wrote:
> > > > After installing the 014_amdlfence patch released yesterday for 6.3, my
> > > > OpenBSD VM crashes on boot. It's running under KVM on a Linux box
> > > > (Ubuntu
> > > > 18.04 w/ kernel 4.15) on an AMD Ryzen 7 1700 (microcode 0x8001137).
> > > > I suppose this would also happen on vmm(4) and bhyve, however I don't
> > > > have
> > > > any such AMD hosts available for testing.
> > >
> > > Hi Elmer,
> > >
> > > This was tested in vmm(4), which does work, unfortunately there was not
> > > extensive testing by in other virtualization software. The MSR that is
> > > being set here is only mentioned in AMDs whitepaper and I had no reason
> > > to believe any special consideration was needed for guest VMs on AMD
> > > processors.
> > >
> > > > It occurs both using libvirt's "EPYC" CPU model and using
> > > > "host-passthrough"
> > > > (i.e. no virtual CPU model), but the "core2duo" CPU model works fine.
> > > >
> > > > I guess not many people are running OpenBSD as a VM, and even less on
> > > > AMD
> > > > hardware. But still, a syspatch leaving the system unable to boot is
> > > > probably not a good thing. :)
> > > >
> > >
> > > Even so, I would like to apologize. This situation is unfortunate, and
> > > I'll try to work with other developers to find the best way forward.
> > > But, I regret I am only but an amateur magician.
> > >
> > > -Bryan.
> >
> > Actually, it looks like this is at least partially a KVM/QEMU bug. In
> > the meantime I guess the solution would be to do as you suggested and
> > set a different CPU model for now until Linux distros include a fix for
> > this.
> >
> > https://lkml.org/lkml/2018/2/21/1202
> >
> > Afterwards, on the OpenBSD side, it looks like one small change may be
> > required in addition..
> >
> > -Bryan.
> >
> > Index: sys/arch/amd64/amd64/identcpu.c
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
> > retrieving revision 1.95.2.2
> > diff -u -p -u -r1.95.2.2 identcpu.c
> > --- sys/arch/amd64/amd64/identcpu.c 30 Jul 2018 14:45:05 - 1.95.2.2
> > +++ sys/arch/amd64/amd64/identcpu.c 1 Aug 2018 16:09:50 -
> > @@ -650,8 +650,10 @@ identifycpu(struct cpu_info *ci)
> >
> > msr = rdmsr(MSR_DE_CFG);
> > #define DE_CFG_SERIALIZE_LFENCE(1 << 1)
> > - msr |= DE_CFG_SERIALIZE_LFENCE;
> > - wrmsr(MSR_DE_CFG, msr);
> > + if ((msr & DE_CFG_SERIALIZE_LFENCE) == 0) {
> > + msr |= DE_CFG_SERIALIZE_LFENCE;
> > + wrmsr(MSR_DE_CFG, msr);
> > + }
> > }
> > }
> >
> >
>
> As expected, -current works properly on real AMD hardware. So my assumption
> about KVM doing something odd seems to be correct.
>
> The issue should be reported upstream to the KVM folks. But if the diff above
> also fixes the issue (I didn't test because I cannot reproduce it), ok
> mlarkin.
>
> -ml
I committed a fix for the potential MSR write #GP bug to -current:
https://marc.info/?l=openbsd-cvs&m=153315564121057&w=2
Unfortunately, for the MSR read issue on older KVMs, it would require
adding additional code to determine if we're running under KVM, there's
really not much at all we can do here..
I agree these seem like KVM bugs, as this does not happen on real
hardware, and at least also not in OpenBSD vmm(4).
-Bryan.
OpenBSD Guest under QEMU fails with pid 1 signal 11
I am trying to create OpenBSD images for use in Google Compute Engine using an expect script [1]. The expect script is able to drive the OpenBSD installation process successfully, but the created images fail to boot cleanly with a long stream of "Process (pid 1) got signal 11". To reproduce try the following (please note that all my tests are on a macOS host with QEMU installed): - Clone the GitHub project at [2] - Assuming you have QEMU installed and install63.iso downloaded try the command: ./imgtool PATH/TO/install63.iso openbsd/base - The openbsd/base expect script will boot the image and you should see the stream of "Process (pid 1) got signal 11". If not, try running the created image: ./imgtool install63-base.tar.gz shared/run Thank you for your help. Bill [1] https://github.com/billziss-gh/pmci.img/blob/master/openbsd/base [2] https://github.com/billziss-gh/pmci.img
