Re: [v3] amd64: simplify TSC sync testing
> First, you need to update to the latest firmware. Maybe they already > fixed the problem. I don't see any mention of the TSC in the BIOS > changelog for the e495 but maybe you'll get lucky. > > Second, if they haven't fixed the problem with the latest firmware, I > recommend you reach out to Lenovo and report the problem. > > Lenovo seem to have been sympathetic to reports about TSC desync in > the past on other models and issued firmware fixes. For example, > the v1.28 firmware for the ThinkPad A485 contained a fix for what > I assume is a very similar problem to the one you're having: > > https://download.lenovo.com/pccbbs/mobiles/r0wuj65wd.txt > > And this forum post, for example, got some response from Lenovo staff: > > https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T-series-Laptops/T14s-G1-AMD-TSC-clock-unusable/m-p/5070296?page=1 > > So, open a post for your model and cite the other posts. > > They might not be sympathetic to the fact that you're seeing the issue > on OpenBSD. If that's a problem you should be able to reproduce the > problem with a recent Linux kernel. The Linux kernel runs a similar > sync test during boot and will complain if the TSCs are not > synchronized. > > Honestly, to save time you may want to just boot up a supported Linux > distribution and grab the error message before you ask for support. > I can confirm that this is also the case with Linux. This is the output of dmesg on Void Linux: [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 2096.114 MHz processor ... ... [1.314252] TSC synchronization [CPU#0 -> CPU#1]: [1.314252] Measured 6615806646 cycles TSC warp between CPUs, turning off TSC clock. [1.314252] tsc: Marking TSC unstable due to check_tsc_sync_source failed [1.314397] #2 #3 #4 #5 #6 #7 Not sure if Void is a Lenovo supported Linux distribution, still though I think it's worth reporting. Thanks
Re: [v3] amd64: simplify TSC sync testing
> This is expected behavior with the patch. > > cpu0's TSC is way out of sync with every > other CPU's TSC, so the TSC is marked > as a bad timecounter and a different one is > chosen. Yes, I can see. Just want to add that without your latest patch the kernel chooses the TSC as clocksource, however only the *user* TSC was disabled (cpu1: disabling user TSC (skew=-5028216492)). > Are you running the latest BIOS available > for your machine? No, I don't think I am. Thanks
Re: [SPAM] Re: [v3] amd64: simplify TSC sync testing
icpu4 at acpi0: C2(0@400 io@0x414), C1(0@1 mwait), PSS acpicpu5 at acpi0: C2(0@400 io@0x414), C1(0@1 mwait), PSS acpicpu6 at acpi0: C2(0@400 io@0x414), C1(0@1 mwait), PSS acpicpu7 at acpi0: C2(0@400 io@0x414), C1(0@1 mwait), PSS acpivideo0 at acpi0: VGA_ acpivout0 at acpivideo0: LCD_ cpu0: 2096 MHz: speeds: 2100 1700 1400 MHz pci0 at mainbus0 bus 0 ksmn0 at pci0 dev 0 function 0 "AMD 17h/1xh Root Complex" rev 0x00 "AMD 17h/1xh IOMMU" rev 0x00 at pci0 dev 0 function 2 not configured pchb0 at pci0 dev 1 function 0 "AMD 17h PCIE" rev 0x00 ppb0 at pci0 dev 1 function 1 "AMD 17h/1xh PCIE" rev 0x00: msi pci1 at ppb0 bus 1 nvme0 at pci1 dev 0 function 0 "SK hynix BC501 NVMe" rev 0x00: msix, NVMe 1.2 nvme0: HFM256GDHTNG-8510B, firmware 80020C00, serial X scsibus1 at nvme0: 2 targets, initiator 0 sd0 at scsibus1 targ 1 lun 0: sd0: 244198MB, 512 bytes/sector, 500118192 sectors ppb1 at pci0 dev 1 function 2 "AMD 17h/1xh PCIE" rev 0x00: msi pci2 at ppb1 bus 2 re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU (0x5080), msi, address xx:xx:xx:xx:xx:xx rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 ppb2 at pci0 dev 1 function 3 "AMD 17h/1xh PCIE" rev 0x00: msi pci3 at ppb2 bus 3 sdhc0 at pci3 dev 0 function 0 "O2 Micro 0Z8621 SD/MMC" rev 0x01: apic 33 int 8 sdhc0: SDHC 4.0, 50 MHz base clock sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed, ddr52, dma ppb3 at pci0 dev 1 function 6 "AMD 17h/1xh PCIE" rev 0x00: msi pci4 at ppb3 bus 4 iwm0 at pci4 dev 0 function 0 "Intel Dual Band Wireless-AC 9260" rev 0x29, msix pchb1 at pci0 dev 8 function 0 "AMD 17h PCIE" rev 0x00 ppb4 at pci0 dev 8 function 1 "AMD 17h/1xh PCIE" rev 0x00 pci5 at ppb4 bus 5 amdgpu0 at pci5 dev 0 function 0 "ATI Picasso" rev 0xc2 drm0 at amdgpu0 amdgpu0: msi azalia0 at pci5 dev 0 function 1 "ATI Radeon Vega HD Audio" rev 0x00: msi azalia0: no supported codecs ccp0 at pci5 dev 0 function 2 "AMD 17h/1xh Crypto" rev 0x00 xhci0 at pci5 dev 0 function 3 "AMD 17h/1xh xHCI" rev 0x00: msi, xHCI 1.10 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1 xhci1 at pci5 dev 0 function 4 "AMD 17h/1xh xHCI" rev 0x00: msi, xHCI 1.10 usb1 at xhci1: USB revision 3.0 uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1 "AMD 17h/1xh I2S Audio" rev 0x00 at pci5 dev 0 function 5 not configured azalia1 at pci5 dev 0 function 6 "AMD 17h/1xh HD Audio" rev 0x00: apic 33 int 30 azalia1: codecs: Conexant/0x1f86 audio0 at azalia1 piixpm0 at pci0 dev 20 function 0 "AMD FCH SMBus" rev 0x61: SMI iic0 at piixpm0 spdmem0 at iic0 addr 0x50: 8GB DDR4 SDRAM PC4-21300 SO-DIMM iic1 at piixpm0 pcib0 at pci0 dev 20 function 3 "AMD FCH LPC" rev 0x51 pchb2 at pci0 dev 24 function 0 "AMD 17h/1xh Data Fabric" rev 0x00 pchb3 at pci0 dev 24 function 1 "AMD 17h/1xh Data Fabric" rev 0x00 pchb4 at pci0 dev 24 function 2 "AMD 17h/1xh Data Fabric" rev 0x00 pchb5 at pci0 dev 24 function 3 "AMD 17h/1xh Data Fabric" rev 0x00 pchb6 at pci0 dev 24 function 4 "AMD 17h/1xh Data Fabric" rev 0x00 pchb7 at pci0 dev 24 function 5 "AMD 17h/1xh Data Fabric" rev 0x00 pchb8 at pci0 dev 24 function 6 "AMD 17h/1xh Data Fabric" rev 0x00 pchb9 at pci0 dev 24 function 7 "AMD 17h/1xh Data Fabric" rev 0x00 isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 wsmouse1 at pms0 mux 0 pms0: Synaptics clickpad, firmware 10.32, 0x1e2a1 0x940300 0x378f40 0xf014a3 0x12e800 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 vmm0 at mainbus0: SVM/RVI efifb at mainbus0 not configured ugen0 at uhub1 port 1 "Intel Bluetooth" rev 2.00/0.02 addr 2 uvideo0 at uhub1 port 2 configuration 1 interface 0 "Chicony Electronics Co.,Ltd. Integrated Camera" rev 2.01/26.99 addr 3 video0 at uvideo0 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets sd1 at scsibus3 targ 1 lun 0: sd1: 223231MB, 512 bytes/sector, 457178608 sectors root on sd1a (.a) swap on sd1b dump on sd1b iwm0: hw rev 0x320, fw ver 46.4e1ceb39.0, address xx:xx:xx:xx:xx:xx amdgpu0: PICASSO 8 CU rev 0x01 amdgpu0: 1920x1080, 32bpp wsdisplay0 at amdgpu0 mux 1: console (std, vt100 emulation), using wskbd0 wsdisplay0: screen 1-5 added (std, vt100 emulation) On Tue, Jul 05, 2022 at 09:47:14PM -0500, Scott Cheloha wrote: > > On Jul 5, 2022, at 21:31, Mohamed Aslan wrote: > > > > ???Hello, > > > > I just tested your patch on my lenovo e495 laptop, unfortunately > > still no tsc. > > > > $ dmesg | gr
Re: [v3] amd64: simplify TSC sync testing
Sorry the `sysctl kern.timecounter` was before your patch. Here's the one after your patch: $ sysctl kern.timecounter kern.timecounter.tick=1 kern.timecounter.timestepwarnings=0 kern.timecounter.hardware=i8254 kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) acpitimer0(1000) On Tue, Jul 05, 2022 at 10:31:33PM -0400, Mohamed Aslan wrote: > Hello, > > I just tested your patch on my lenovo e495 laptop, unfortunately > still no tsc. > > $ dmesg | grep 'tsc:' > tsc: cpu0/cpu1 sync round 1: 20468 regressions > tsc: cpu0/cpu1 sync round 1: cpu0 lags cpu1 by 5351060292 cycles > tsc: cpu0/cpu1 sync round 1: cpu1 lags cpu0 by 0 cycles > tsc: cpu0/cpu2 sync round 1: 10272 regressions > tsc: cpu0/cpu2 sync round 1: cpu0 lags cpu2 by 5351060271 cycles > tsc: cpu0/cpu2 sync round 1: cpu2 lags cpu0 by 0 cycles > tsc: cpu0/cpu3 sync round 1: 9709 regressions > tsc: cpu0/cpu3 sync round 1: cpu0 lags cpu3 by 5351060271 cycles > tsc: cpu0/cpu3 sync round 1: cpu3 lags cpu0 by 0 cycles > tsc: cpu0/cpu4 sync round 1: 10386 regressions > tsc: cpu0/cpu4 sync round 1: cpu0 lags cpu4 by 5351060271 cycles > tsc: cpu0/cpu4 sync round 1: cpu4 lags cpu0 by 0 cycles > tsc: cpu0/cpu5 sync round 1: 10408 regressions > tsc: cpu0/cpu5 sync round 1: cpu0 lags cpu5 by 5351060271 cycles > tsc: cpu0/cpu5 sync round 1: cpu5 lags cpu0 by 0 cycles > tsc: cpu0/cpu6 sync round 1: 10102 regressions > tsc: cpu0/cpu6 sync round 1: cpu0 lags cpu6 by 5351060271 cycles > tsc: cpu0/cpu6 sync round 1: cpu6 lags cpu0 by 0 cycles > tsc: cpu0/cpu7 sync round 1: 9336 regressions > tsc: cpu0/cpu7 sync round 1: cpu0 lags cpu7 by 5351060271 cycles > tsc: cpu0/cpu7 sync round 1: cpu7 lags cpu0 by 0 cycles > > $ sysctl kern.timecounter > kern.timecounter.tick=1 > kern.timecounter.timestepwarnings=0 > kern.timecounter.hardware=tsc > kern.timecounter.choice=i8254(0) tsc(2000) acpihpet0(1000) acpitimer0(1000) > > $ sysctl hw > hw.model=AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx > hw.ncpu=8 > hw.vendor=LENOVO > hw.product=20NE0002US > hw.version=ThinkPad E495 > hw.ncpufound=8 > hw.smt=0 > hw.ncpuonline=4 > > > Best, > M. > > > On Mon, Jul 04, 2022 at 09:06:55PM -0500, Scott Cheloha wrote: > > Hi, > > > > Once again, I am trying to change our approach to TSC sync testing to > > eliminate false positive results. Instead of trying to repair the TSC > > by measuring skew, we just spin in a lockless loop looking for skew > > and mark the TSC as broken if we detect any. > > > > This is motivated in part by some multisocket machines that do not use > > the TSC as a timecounter because the current sync test confuses NUMA > > latency for TSC skew. > > > > The only difference between this version and the prior version (v2) is > > that we check whether we have the IA32_TSC_ADJUST register by hand in > > tsc_reset_adjust(). If someone wants to help me rearrange cpu_hatch() > > so we do CPU identification before TSC sync testing we can remove the > > workaround later. > > > > If you have the IA32_TSC_ADJUST register and it is non-zero going into > > the test, you will see something on the console like this: > > > > tsc: cpu5: IA32_TSC_ADJUST: -150 -> 0 > > > > This does *not* mean you failed the test. It just means you probably > > have a bug in your BIOS (or some other firmware) and you should report > > it to your vendor. > > > > If you fail the test you will see something like this: > > > > tsc: cpu0/cpu2: sync test round 1/2 failed > > tsc: cpu0/cpu2: cpu2: 13043 lags 438 cycles > > > > A printout like this would mean that the sync test for cpu2 failed. > > In particular, cpu2's TSC trails cpu0's TSC by at least 438 cycles. > > If this happens for *any* CPU we mark the TSC timecounter as > > defective. > > > > -- > > > > Please test! Send your dmesg, pass or fail. > > > > I am especially interested in: > > > > 1. A test from dv@. Your dual-socket machine has the IA32_TSC_ADJUST > >register but it failed the test running patch v2. Maybe it will pass > >with this version? > > > > 2. Other multisocket machines. > > > > 3. There were reports of TSC issues with OpenBSD VMs running on ESXi. > >What happens when you run with this patch? > > > > 4. OpenBSD VMs on other hypervisors. > > > > 5. Non-Lenovo machines, non-Intel machines. > > > > -Scott > > > > Index: amd64/tsc.c > > === > > RCS file: /cvs/src/sys/arch/amd64/amd64/tsc.c,v >
Re: [v3] amd64: simplify TSC sync testing
What I meant in my first email is, it seems that before applying your patch, the tsc was used as the hardware counter (no user TSC though), but after applying your patch the i8254 was the one being used. Thanks On Tue, Jul 05, 2022 at 10:34:54PM -0400, Mohamed Aslan wrote: > Sorry the `sysctl kern.timecounter` was before your patch. > > Here's the one after your patch: > $ sysctl kern.timecounter > kern.timecounter.tick=1 > kern.timecounter.timestepwarnings=0 > kern.timecounter.hardware=i8254 > kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) acpitimer0(1000) > > > > On Tue, Jul 05, 2022 at 10:31:33PM -0400, Mohamed Aslan wrote: > > Hello, > > > > I just tested your patch on my lenovo e495 laptop, unfortunately > > still no tsc. > > > > $ dmesg | grep 'tsc:' > > tsc: cpu0/cpu1 sync round 1: 20468 regressions > > tsc: cpu0/cpu1 sync round 1: cpu0 lags cpu1 by 5351060292 cycles > > tsc: cpu0/cpu1 sync round 1: cpu1 lags cpu0 by 0 cycles > > tsc: cpu0/cpu2 sync round 1: 10272 regressions > > tsc: cpu0/cpu2 sync round 1: cpu0 lags cpu2 by 5351060271 cycles > > tsc: cpu0/cpu2 sync round 1: cpu2 lags cpu0 by 0 cycles > > tsc: cpu0/cpu3 sync round 1: 9709 regressions > > tsc: cpu0/cpu3 sync round 1: cpu0 lags cpu3 by 5351060271 cycles > > tsc: cpu0/cpu3 sync round 1: cpu3 lags cpu0 by 0 cycles > > tsc: cpu0/cpu4 sync round 1: 10386 regressions > > tsc: cpu0/cpu4 sync round 1: cpu0 lags cpu4 by 5351060271 cycles > > tsc: cpu0/cpu4 sync round 1: cpu4 lags cpu0 by 0 cycles > > tsc: cpu0/cpu5 sync round 1: 10408 regressions > > tsc: cpu0/cpu5 sync round 1: cpu0 lags cpu5 by 5351060271 cycles > > tsc: cpu0/cpu5 sync round 1: cpu5 lags cpu0 by 0 cycles > > tsc: cpu0/cpu6 sync round 1: 10102 regressions > > tsc: cpu0/cpu6 sync round 1: cpu0 lags cpu6 by 5351060271 cycles > > tsc: cpu0/cpu6 sync round 1: cpu6 lags cpu0 by 0 cycles > > tsc: cpu0/cpu7 sync round 1: 9336 regressions > > tsc: cpu0/cpu7 sync round 1: cpu0 lags cpu7 by 5351060271 cycles > > tsc: cpu0/cpu7 sync round 1: cpu7 lags cpu0 by 0 cycles > > > > $ sysctl kern.timecounter > > kern.timecounter.tick=1 > > kern.timecounter.timestepwarnings=0 > > kern.timecounter.hardware=tsc > > kern.timecounter.choice=i8254(0) tsc(2000) acpihpet0(1000) acpitimer0(1000) > > > > $ sysctl hw > > hw.model=AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx > > hw.ncpu=8 > > hw.vendor=LENOVO > > hw.product=20NE0002US > > hw.version=ThinkPad E495 > > hw.ncpufound=8 > > hw.smt=0 > > hw.ncpuonline=4 > > > > > > Best, > > M. > > > > > > On Mon, Jul 04, 2022 at 09:06:55PM -0500, Scott Cheloha wrote: > > > Hi, > > > > > > Once again, I am trying to change our approach to TSC sync testing to > > > eliminate false positive results. Instead of trying to repair the TSC > > > by measuring skew, we just spin in a lockless loop looking for skew > > > and mark the TSC as broken if we detect any. > > > > > > This is motivated in part by some multisocket machines that do not use > > > the TSC as a timecounter because the current sync test confuses NUMA > > > latency for TSC skew. > > > > > > The only difference between this version and the prior version (v2) is > > > that we check whether we have the IA32_TSC_ADJUST register by hand in > > > tsc_reset_adjust(). If someone wants to help me rearrange cpu_hatch() > > > so we do CPU identification before TSC sync testing we can remove the > > > workaround later. > > > > > > If you have the IA32_TSC_ADJUST register and it is non-zero going into > > > the test, you will see something on the console like this: > > > > > > tsc: cpu5: IA32_TSC_ADJUST: -150 -> 0 > > > > > > This does *not* mean you failed the test. It just means you probably > > > have a bug in your BIOS (or some other firmware) and you should report > > > it to your vendor. > > > > > > If you fail the test you will see something like this: > > > > > > tsc: cpu0/cpu2: sync test round 1/2 failed > > > tsc: cpu0/cpu2: cpu2: 13043 lags 438 cycles > > > > > > A printout like this would mean that the sync test for cpu2 failed. > > > In particular, cpu2's TSC trails cpu0's TSC by at least 438 cycles. > > > If this happens for *any* CPU we mark the TSC timecounter as > > > defective. > > > > > > -- > > > > > > Please test! Send your dmesg, pass or fail. > >
Re: [v3] amd64: simplify TSC sync testing
endif
> } else {
> /*
> - * Synchronize time stamp counters. Invalidate cache and
> - * synchronize twice (in tsc_sync_bp) to minimize possible
> - * cache effects. Disable interrupts to try and rule out any
> - * external interference.
> + * Test if TSCs are synchronized. Invalidate cache to
> + * minimize possible cache effects. Disable interrupts to
> + * rule out external interference.
>*/
> s = intr_disable();
> wbinvd();
> - tsc_sync_bp(ci);
> + tsc_test_sync_bp(ci);
> intr_restore(s);
> -#ifdef TSC_DEBUG
> - printf("TSC skew=%lld\n", (long long)ci->ci_tsc_skew);
> -#endif
> }
>
> if ((ci->ci_flags & CPUF_IDENTIFIED) == 0) {
> @@ -890,7 +886,6 @@ void
> cpu_boot_secondary(struct cpu_info *ci)
> {
> int i;
> - int64_t drift;
> u_long s;
>
> atomic_setbits_int(>ci_flags, CPUF_GO);
> @@ -905,18 +900,11 @@ cpu_boot_secondary(struct cpu_info *ci)
> db_enter();
> #endif
> } else if (cold) {
> - /* Synchronize TSC again, check for drift. */
> - drift = ci->ci_tsc_skew;
> + /* Test if TSCs are synchronized again. */
> s = intr_disable();
> wbinvd();
> - tsc_sync_bp(ci);
> + tsc_test_sync_bp(ci);
> intr_restore(s);
> - drift -= ci->ci_tsc_skew;
> -#ifdef TSC_DEBUG
> - printf("TSC skew=%lld drift=%lld\n",
> - (long long)ci->ci_tsc_skew, (long long)drift);
> -#endif
> - tsc_sync_drift(drift);
> }
> }
>
> @@ -942,13 +930,12 @@ cpu_hatch(void *v)
> #endif
>
> /*
> - * Synchronize the TSC for the first time. Note that interrupts are
> - * off at this point.
> + * Test if our TSC is synchronized for the first time.
> + * Note that interrupts are off at this point.
>*/
> wbinvd();
> ci->ci_flags |= CPUF_PRESENT;
> - ci->ci_tsc_skew = 0;/* reset on resume */
> - tsc_sync_ap(ci);
> + tsc_test_sync_ap(ci);
>
> lapic_enable();
> lapic_startclock();
> Index: include/cpu.h
> ===
> RCS file: /cvs/src/sys/arch/amd64/include/cpu.h,v
> retrieving revision 1.144
> diff -u -p -r1.144 cpu.h
> --- include/cpu.h 28 Jun 2022 12:11:41 - 1.144
> +++ include/cpu.h 5 Jul 2022 01:52:11 -
> @@ -209,8 +209,6 @@ struct cpu_info {
> paddr_t ci_vmxon_region_pa;
> struct vmxon_region *ci_vmxon_region;
>
> - int64_t ci_tsc_skew;/* counter skew vs cpu0 */
> -
> charci_panicbuf[512];
>
> paddr_t ci_vmcs_pa;
> @@ -230,7 +228,6 @@ struct cpu_info {
> #define CPUF_INVAR_TSC 0x0100 /* CPU has invariant TSC */
> #define CPUF_USERXSTATE 0x0200 /* CPU has curproc's xsave
> state */
>
> -#define CPUF_SYNCTSC 0x0800 /* Synchronize TSC */
> #define CPUF_PRESENT 0x1000 /* CPU is present */
> #define CPUF_RUNNING 0x2000 /* CPU is running */
> #define CPUF_PAUSE 0x4000 /* CPU is paused in DDB */
> Index: include/cpuvar.h
> ===
> RCS file: /cvs/src/sys/arch/amd64/include/cpuvar.h,v
> retrieving revision 1.11
> diff -u -p -r1.11 cpuvar.h
> --- include/cpuvar.h 16 May 2021 04:33:05 - 1.11
> +++ include/cpuvar.h 5 Jul 2022 01:52:11 -
> @@ -97,8 +97,7 @@ void identifycpu(struct cpu_info *);
> void cpu_init(struct cpu_info *);
> void cpu_init_first(void);
>
> -void tsc_sync_drift(int64_t);
> -void tsc_sync_bp(struct cpu_info *);
> -void tsc_sync_ap(struct cpu_info *);
> +void tsc_test_sync_bp(struct cpu_info *);
> +void tsc_test_sync_ap(struct cpu_info *);
>
> #endif
>
--
Mohamed 'Aslan' Abdelsalam, Ph.D.
http://www.sce.carleton.ca/~maslan/
Re: Microkernel
A decade ago, there was an experiment to port OpenBSD to the L4/Fiasco microkernel [1]. However, if I remember correctly, it was not a multi-server port, someone please correct me if i am wrong. Regards, Aslan [1] https://www.isti.tu-berlin.de/fileadmin/fg214/finished_theses/cludwig/OpenBSDonFiasco.pdf On Sat, May 21, 2022 at 10:07:01PM +0200, Daniel Douglas Dyrseth wrote: > Hi > Is porting natively a microkernel like seL4, Minix's or rewriting one for > OpenBSD an option and something the developers could implement? I see this as > an excellent addition to the already most robust OS in the world. > > Sincerely > Daniel Douglas Dyrseth >
Re: amd64: simplify TSC sync testing
Hello, I can confirm the same behaviour with this patch applied. $ sysctl kern.timecounter kern.timecounter.tick=1 kern.timecounter.timestepwarnings=0 kern.timecounter.hardware=i8254 kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) acpitimer0(1000) $ sysctl hw hw.machine=amd64 hw.model=AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx hw.ncpu=8 hw.vendor=LENOVO hw.version=ThinkPad E495 Regards, Aslan On Wed, Feb 02, 2022 at 01:51:18PM -0500, Dave Voutila wrote: > > Jason McIntyre writes: > > > On Wed, Feb 02, 2022 at 04:52:40PM +, Stuart Henderson wrote: > >> This definitely wants testing on Ryzen ThinkPads (e.g. > >> E485/E585/X395/T495s) > >> or Inspiron 5505, I see user TSC disabled on a lot of those in dmesglog. > >> > >> > > > > hi. > > > > here are the results from a 5505. was the timecounter meant to switch > > from tsc? > > > > jmc > > > > $ sysctl kern.timecounter > > kern.timecounter.tick=1 > > kern.timecounter.timestepwarnings=0 > > kern.timecounter.hardware=i8254 > > kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) acpitimer0(1000) > > > > I'm seeing the same issue...switching to i8254 pit where before it was > using tsc. :( > > This is a Lenovo X13. dmesg and sysctl output follows. > > -dv > > $ sysctl kern.timecounter > kern.timecounter.tick=1 > kern.timecounter.timestepwarnings=0 > kern.timecounter.hardware=i8254 > kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) acpitimer0(1000) > > > OpenBSD 7.0-current (CUSTOM.MP) #4: Wed Feb 2 13:24:56 EST 2022 > d...@kogelvis2.sisu.home:/usr/src/sys/arch/amd64/compile/CUSTOM.MP > real mem = 16301219840 (15546MB) > avail mem = 15664230400 (14938MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xbf711000 (69 entries) > bios0: vendor LENOVO version "R1CET63W(1.32 )" date 04/09/2021 > bios0: LENOVO 20UF0013US > acpi0 at bios0: ACPI 6.3 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SSDT SSDT SSDT IVRS SSDT SSDT TPM2 SSDT MSDM BATB > HPET APIC MCFG SBST WSMT VFCT SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI SSDT > SSDT BGRT > acpi0: wakeup devices GPP0(S3) RESA(S3) GPP4(S4) GPP5(S3) L850(S3) GPP6(S3) > GPP7(S3) GP17(S3) XHC0(S3) XHC1(S3) LID_(S4) SLPB(S3) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpihpet0 at acpi0: 14318180 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Ryzen 5 PRO 4650U with Radeon Graphics, 2096.39 MHz, 17-60-01 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > 64b/line 8-way L2 cache > cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=1.1, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD Ryzen 5 PRO 4650U with Radeon Graphics, 2096.06 MHz, 17-60-01 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu1: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > 64b/line 8-way L2 cache > cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu1: smt 1, core 0, package 0 > cpu2 at mainbus0: apid 2 (application processor) > tsc: cpu0/cpu2 sync round 1: 1093 regressions > tsc: cpu0/cpu2 sync round 1: cpu0 lags cpu2 by 0 cycles > tsc: cpu0/cpu2 sync round 1: cpu2 lags cpu0 by 21 cycles > cpu2: AMD Ryzen 5 PRO 4650U with Radeon Graphics, 2096.06 MHz, 17-60-01 > cpu2: >
Re: Secure by default
How's is this related to tech@? On Sun, Feb 14, 2021 at 12:44:00AM +0530, sivasubramanian muthusamy wrote: > Hello, > > I am an ordinary computer user, installed 6.8 without connecting to > the Internet yet, (a friend and a technical expert recently advised me > in a different context: do not expose your machine to the Internet- > don't know what that means) > > OpenBSD intro says OpenBSD is secure by default. How is it secure by > default for an average user who does not get to ssh, does not use his > computer as a web-server or as a VM host, who does not have to share > screen etc? What ports are open by default and what applications start > by default? > > Before connecting the computer to the Internet, what other steps > should a very ordinary user take? Block a few more ports? Which ones? > > Thank you. > > Sivasubramanian M >
vmd: enable pause/unpause for vm owners
Hello tech@,
I noticed that vmd(8) only allows VM owners to start/stop their
VMs, but does not let them to pause/unpause those VMs.
I was just wondering if there are reasons behind that. If not, the
patch below enables pause/unpause commands for VM owners.
Regards,
Aslan
Index: control.c
===
RCS file: /cvs/src/usr.sbin/vmd/control.c,v
retrieving revision 1.22
diff -u -p -r1.22 control.c
--- control.c 8 Sep 2017 06:24:31 - 1.22
+++ control.c 16 Apr 2018 04:40:24 -
@@ -340,6 +340,8 @@ control_dispatch_imsg(int fd, short even
case IMSG_VMDOP_GET_INFO_VM_REQUEST:
case IMSG_VMDOP_TERMINATE_VM_REQUEST:
case IMSG_VMDOP_START_VM_REQUEST:
+ case IMSG_VMDOP_PAUSE_VM:
+ case IMSG_VMDOP_UNPAUSE_VM:
break;
default:
if (c->peercred.uid != 0) {
@@ -373,8 +375,6 @@ control_dispatch_imsg(int fd, short even
/* FALLTHROUGH */
case IMSG_VMDOP_RECEIVE_VM_REQUEST:
case IMSG_VMDOP_SEND_VM_REQUEST:
- case IMSG_VMDOP_PAUSE_VM:
- case IMSG_VMDOP_UNPAUSE_VM:
case IMSG_VMDOP_LOAD:
case IMSG_VMDOP_RELOAD:
case IMSG_CTL_RESET:
@@ -421,6 +421,21 @@ control_dispatch_imsg(int fd, short even
control_close(fd, cs);
return;
}
+ break;
+ case IMSG_VMDOP_PAUSE_VM:
+ case IMSG_VMDOP_UNPAUSE_VM:
+ if (IMSG_DATA_SIZE() < sizeof(vid))
+ goto fail;
+ memcpy(, imsg.data, sizeof(vid));
+ vid.vid_uid = c->peercred.uid;
+ log_debug("%s id: %d, name: %s, uid: %d",
+ __func__, vid.vid_id, vid.vid_name,
+ vid.vid_uid);
+
+ if (proc_compose_imsg(ps, PROC_PARENT, -1,
+ imsg.hdr.type, fd, imsg.fd,
+ , sizeof(vid)) == -1)
+ goto fail;
break;
default:
log_debug("%s: error handling imsg %d",
Index: vm.conf.5
===
RCS file: /cvs/src/usr.sbin/vmd/vm.conf.5,v
retrieving revision 1.27
diff -u -p -r1.27 vm.conf.5
--- vm.conf.5 3 Jan 2018 05:39:56 - 1.27
+++ vm.conf.5 16 Apr 2018 04:40:24 -
@@ -206,7 +206,8 @@ Memory size of the VM, in bytes, rounded
The default is 512M.
.It Cm owner Ar user Ns Op : Ns Ar group
Set the owner of the VM to the specified user or group.
-The owner will be allowed to start or stop the VM and open the VM's console.
+The owner will be allowed to start or stop the VM, pause or unpause the VM,
+and open the VM's console.
.It Cm owner Pf : Ar group
Set the owner to the specified group.
.El
Index: vmd.c
===
RCS file: /cvs/src/usr.sbin/vmd/vmd.c,v
retrieving revision 1.82
diff -u -p -r1.82 vmd.c
--- vmd.c 29 Mar 2018 18:29:24 - 1.82
+++ vmd.c 16 Apr 2018 04:40:25 -
@@ -186,8 +186,13 @@ vmd_dispatch_control(int fd, struct priv
} else {
vid.vid_id = vm->vm_vmid;
}
- } else if (vm_getbyid(vid.vid_id) == NULL) {
+ } else if ((vm = vm_getbyid(vid.vid_id)) == NULL) {
res = ENOENT;
+ cmd = IMSG_VMDOP_PAUSE_VM_RESPONSE;
+ break;
+ }
+ if (vm_checkperm(vm, vid.vid_uid) != 0) {
+ res = EPERM;
cmd = IMSG_VMDOP_PAUSE_VM_RESPONSE;
break;
}
