Re: Some bwfm(4) diffs

2023-10-08 Thread Mike Larkin
On Sun, Oct 08, 2023 at 07:42:54PM +0200, Mark Kettenis wrote: > Hector Martin has added support for the BCM4388 that is found on the > last generation of Apple Macs. Based on his commits I've managed to > get it working on my M2 Pro mini. I still have to clean up some of > that stuff, but here

Re: vmd(8): fix deadlock during pausing

2023-09-25 Thread Mike Larkin
On Sun, Sep 24, 2023 at 01:07:43AM -0400, Dave Voutila wrote: > vmd has a sneaky little deadlock hidden in the pause logic related to > the use of mutexes and condition variables. > > When pausing, the vcpu is holding the "run" mutex. It then sleeps > waiting for the unpause condition. If the

Re: Dell R7615 kernel protection fault

2023-09-11 Thread Mike Larkin
On Mon, Sep 11, 2023 at 03:23:28PM +0200, Hrvoje Popovski wrote: > On 11.9.2023. 6:27, Hrvoje Popovski wrote: > > On 11.9.2023. 2:48, Mike Larkin wrote: > >> On Sun, Sep 10, 2023 at 01:36:33AM +0200, Hrvoje Popovski wrote: > >>> Hi all, > >>> > >>

Re: Dell R7615 kernel protection fault

2023-09-10 Thread Mike Larkin
On Sun, Sep 10, 2023 at 01:36:33AM +0200, Hrvoje Popovski wrote: > Hi all, > > I've installed latest snapshot with uefi on Dell R7615 with AMD EPYC > 9554P, with some NVMe disks on BOSS-N1 adapter and with Samsung NVMe > disks directly connected to backplane and installation was fast and > without

Re: clockintr: add clockintr_advance_random()

2023-09-05 Thread Mike Larkin
On Tue, Sep 05, 2023 at 09:17:27AM -0500, Scott Cheloha wrote: > mpi@ suggests folding the pseudorandom advance code from > clockintr_statclock() into the clockintr API itself. This replaces > three API calls -- clockintr_expiration(), clockintr_nsecuptime(), and > clockintr_schedule() -- we just

Re: vmd/vmm: remove an ioctl from the vcpu hotpath, go brrr

2023-09-04 Thread Mike Larkin
On Mon, Sep 04, 2023 at 07:57:18PM +0200, Mischa wrote: > On 2023-09-04 18:58, Mischa wrote: > > On 2023-09-04 18:55, Mischa wrote: > > > On 2023-09-04 17:57, Dave Voutila wrote: > > > > Mischa writes: > > > > > On 2023-09-04 16:23, Mike Larkin wro

Re: vmd/vmm: remove an ioctl from the vcpu hotpath, go brrr

2023-09-04 Thread Mike Larkin
On Mon, Sep 04, 2023 at 02:30:23PM +0200, Mischa wrote: > On 2023-09-03 21:18, Dave Voutila wrote: > > Mischa writes: > > > > > Nice!! Thanx Dave! > > > > > > Running go brrr as we speak. > > > Testing with someone who is running Debian. > > > > Great. I'll plan on committing this tomorrow

Re: vmd/vmm: remove an ioctl from the vcpu hotpath, go brrr

2023-09-03 Thread Mike Larkin
On Fri, Sep 01, 2023 at 03:50:31PM -0400, Dave Voutila wrote: > Now that my i8259 fix is in, it's safe to expand the testing pool for > this diff. (Without that fix, users would definitely hit the hung block > device issue testing this one.) Hoping that folks that run non-OpenBSD > guests or

Re: all platforms: separate cpu_initclocks() from cpu_startclock()

2023-08-23 Thread Mike Larkin
On Mon, Aug 21, 2023 at 10:23:53PM -0500, Scott Cheloha wrote: > On Tue, Aug 22, 2023 at 02:36:31AM +0000, Mike Larkin wrote: > > On Mon, Aug 21, 2023 at 09:26:00PM -0500, Scott Cheloha wrote: > > > On Mon, Aug 21, 2023 at 10:10:58PM +, Mike Larkin wrote: > > > >

Re: all platforms: separate cpu_initclocks() from cpu_startclock()

2023-08-21 Thread Mike Larkin
On Mon, Aug 21, 2023 at 09:26:00PM -0500, Scott Cheloha wrote: > On Mon, Aug 21, 2023 at 10:10:58PM +0000, Mike Larkin wrote: > > On Sat, Aug 19, 2023 at 01:44:47PM -0500, Scott Cheloha wrote: > > > On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote: > > &g

Re: all platforms: separate cpu_initclocks() from cpu_startclock()

2023-08-21 Thread Mike Larkin
On Sat, Aug 19, 2023 at 01:44:47PM -0500, Scott Cheloha wrote: > On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote: > > This is the next patch in the clock interrupt reorganization series. > > > > Before we continue breaking up the hardclock(9) we need to detour into > > the MD code. >

Re: i386: i8254_initclocks: set IPL_MPSAFE for clock, rtc IRQs

2023-08-21 Thread Mike Larkin
On Sun, Aug 20, 2023 at 10:39:46PM -0500, Scott Cheloha wrote: > pOn amd64 we lie about the interrupts established during > i8254_initclocks(). We claim they are MP-safe in order to mollify a > KASSERT in intr_establish() and continue booting. > > See amd64/isa/clock.c: >279 void >280

Re: vmd(8): fix setting log verbosity in child processes

2023-07-27 Thread Mike Larkin
On Wed, Jul 26, 2023 at 12:23:58PM -0400, Dave Voutila wrote: > When adding exec for vm's and fork/exec'd vio{blk,net} devices, the > current verbosity wasn't being set on the new process. The below change > keeps it simple, avoiding runtime string manipulation. Also tosses in an > ifdef around a

Re: [v2] statclock: move profil(2), GPROF code into other clock interrupts

2023-07-21 Thread Mike Larkin
On Fri, Jul 21, 2023 at 05:46:32PM +0200, Jeremie Courreges-Anglas wrote: > On Thu, Jul 20 2023, Scott Cheloha wrote: > > On Wed, Jul 19, 2023 at 05:09:04AM +0000, Mike Larkin wrote: > >> On Tue, Jul 18, 2023 at 08:21:41AM -0500, Scott Cheloha wrote: > >> >

Re: [v2] statclock: move profil(2), GPROF code into other clock interrupts

2023-07-20 Thread Mike Larkin
On Thu, Jul 20, 2023 at 01:23:01PM -0500, Scott Cheloha wrote: > On Wed, Jul 19, 2023 at 05:09:04AM +0000, Mike Larkin wrote: > > On Tue, Jul 18, 2023 at 08:21:41AM -0500, Scott Cheloha wrote: > > > This patch moves the profil(2)- and GPROF-specific parts of >

Re: ietp cleanup

2023-07-20 Thread Mike Larkin
On Thu, Jul 20, 2023 at 12:58:33PM -0500, joshua stein wrote: > bmercer@ noticed there was no newline printed after a successful attachment. > I did some other minor cleanup removing duplicate dv_xname printing during > attachment and wrapping at 80 chars. > > ok? > ok mlarkin > > Index:

Re: [v2] statclock: move profil(2), GPROF code into other clock interrupts

2023-07-18 Thread Mike Larkin
On Tue, Jul 18, 2023 at 08:21:41AM -0500, Scott Cheloha wrote: > This patch moves the profil(2)- and GPROF-specific parts of > statclock() out into into separate clock interrupt routines. The > profil(2) part moves into profclock() and is enabled/disabled as > needed during mi_switch(). The

Re: all platforms, kernel: remove __HAVE_CLOCKINTR symbol

2023-07-02 Thread Mike Larkin
On Sat, Jul 01, 2023 at 08:35:47PM -0500, Scott Cheloha wrote: > Every platform made the clockintr switch six months ago or more. The > __HAVE_CLOCKINTR symbol is now redundant and can be removed. > > ok? > makes sense if every platform defines it all the time. > Index: ./ddb/db_command.c >

Re: vmm/vmd: use anon shared mappings for devices

2023-05-10 Thread Mike Larkin
On Tue, May 09, 2023 at 06:12:55AM -0400, Dave Voutila wrote: > tech@, > > The diff below adds a new ioctl for vmm(4) that allows an emulated > device process request vmm(4) enter a shared mapping in its vmspace so > it can access guest memory without using a shared mapping backed by a > named

Re: riscv64 RAMDISK: enable softraid

2023-04-25 Thread Mike Larkin
On Tue, Apr 25, 2023 at 01:12:24PM +, Klemens Nanni wrote: > (Thought I already committed this months ago, noticed now looking into > bootloaders again...) > > GENERIC, efiboot and installboot(8) all have softraid support already, > softraid(4) documents boot support for riscv64, > "just" the

Re: vmd: silence error on missing optional config

2023-04-24 Thread Mike Larkin
On Mon, Apr 24, 2023 at 02:29:38PM +, Klemens Nanni wrote: > On Mon, Apr 24, 2023 at 01:46:17PM +, Klemens Nanni wrote: > > I have on vm.conf, vmd does not need it, but complains: > > Apr 23 17:12:50 atar vmd[79320]: failed to open /etc/vm.conf: No such file > > or directory > > > > We've

Re: vmd(8): fix restoring virtio devs on vm receive

2023-04-22 Thread Mike Larkin
On Sun, Apr 16, 2023 at 01:14:00PM -0400, Dave Voutila wrote: > Moving vmd to use zero-copy semantics for virtqueues introduced a bug in > the vm send/receive functionality. The host va is potentially invalid on > restore if vmd has restarted and re-randomized the address space of the > vmm

Re: cleanup vmm_start_vm, simplifying fd cleanup

2023-04-07 Thread Mike Larkin
On Fri, Apr 07, 2023 at 12:07:07PM -0400, Dave Voutila wrote: > > Dave Voutila writes: > > > In vmd, the vmm process forks to create the resulting vm process. After > > this fork, the vmm parent process closes all the file descriptors > > pointing to the vm's devices (cdrom, kernel, disks, nics,

Re: wire in efi_reset on MSFT Surface systems to rix reboots

2023-04-01 Thread Mike Larkin
On Sat, Jan 21, 2023 at 09:59:13AM -0500, Dave Voutila wrote: > I've long moaned about how my Go3 can't reboot. Woe is me. Now that > kettenis@ landed some scaffolding for efi(4), I would love to get my Go3 > working in the reboot department. > > The approach I'm thinking, in the diff below, is to

Re: timer(4/sparc64): remove driver

2023-03-17 Thread Mike Larkin
On Thu, Mar 16, 2023 at 12:25:15PM -0500, Scott Cheloha wrote: > This code has been dead since we switched sparc64 to clockintr several > months ago. Nobody has come forward asking for a timer(4/sparc64) > intrclock. > > As of now, you need %TICK_CMPR or %STICK_CMPR to run OpenBSD on > sparc64.

Re: proc.c: remove some dead code

2023-02-15 Thread Mike Larkin
On Wed, Feb 15, 2023 at 12:02:46PM +0100, Tobias Heider wrote: > Many of our networking daemons use proc.c to set up processes and ipc. I > couldn't > find two that are actually exactly the same, but it looks like none of them > are ever > using proc_ispeer, so here is a diff to delete it from

Re: Add ASMedia ASM2142 xhci

2023-02-07 Thread Mike Larkin
On Tue, Feb 07, 2023 at 02:35:37PM +0800, Kevin Lo wrote: > Hi, > > I have a machine with the ASMedia USB 3.1 controller: > > xhci1 at pci3 dev 0 function 0 vendor "ASMedia", unknown product 0x2142 rev > 0x00: msi, xHCI 1.10 > > ok? > ok mlarkin > Index: sys/dev/pci/pcidevs >

Re: vmd(8): fix serial console race leading to interrupt storm

2023-01-30 Thread Mike Larkin
On Mon, Jan 30, 2023 at 08:03:52PM +, Mike Larkin wrote: > On Mon, Jan 30, 2023 at 12:32:22PM -0500, Dave Voutila wrote: > > vmd's serial console has a race condition and can generate interrupt > > storms as the ns8250 device constantly asserts and deasserts its irq. >

Re: vmd(8): fix serial console race leading to interrupt storm

2023-01-30 Thread Mike Larkin
On Mon, Jan 30, 2023 at 12:32:22PM -0500, Dave Voutila wrote: > vmd's serial console has a race condition and can generate interrupt > storms as the ns8250 device constantly asserts and deasserts its irq. > > Easiest way to see this is on older, slower hardware OR running nested > such as OpenBSD

Re: amd64, i386: set lapic timer mode, mask, divisor once

2023-01-27 Thread Mike Larkin
On Fri, Jan 27, 2023 at 08:07:26AM -0600, Scott Cheloha wrote: > mlarkin@ noted about a month or so ago that setting the lapic timer > mode, mask, and divisor every time we rearm it is unnecessary. We > only need to configure those registers once during > lapic_timer_trigger(). After that, it is

Re: don't remove known vmd vm's on failure

2023-01-26 Thread Mike Larkin
On Sun, Jan 15, 2023 at 09:08:29AM -0500, Dave Voutila wrote: > > Dave Voutila writes: > > > It turns out not only does vmd have numerous error paths for handling > > when something is amiss with a guest, most of the paths don't check if > > it's a known vm defined in vm.conf. > > > > As a

Re: add thread names to vmd(8)

2023-01-10 Thread Mike Larkin
On Sun, Jan 08, 2023 at 10:45:11AM -0800, Philip Guenther wrote: > On Sun, Jan 8, 2023 at 8:50 AM Dave Voutila wrote: > > > Now that guenther@ landed thread names, this should help users > > understand vmd host cpu utilization better as it lets us distinguish > > between the libevent thread and

Re: vmm: mask WAITPKG cpuid feature to hide TPAUSE

2023-01-10 Thread Mike Larkin
On Mon, Jan 09, 2023 at 06:51:27PM -0500, Dave Voutila wrote: > > This ok with folks? Had OK's for the original diff but double checking > before I commit. > This is only half of what you need to do to stop guests from using unwanted/unsupported instructions. Removing the CPUID feature flag bit

Re: ESRT support for the amd64 bootloader

2023-01-03 Thread Mike Larkin
On Wed, Dec 28, 2022 at 09:13:16PM +0100, Mark Kettenis wrote: > Dear Sergii, > > Sorry for the delay, but I have finally found the time to work on the > EFI variable and ESRT support for OpenBSD. As a first step, here is a > diff that adds support for copying the ESRT in the bootloader and >

Re: ESRT support for the amd64 bootloader

2023-01-03 Thread Mike Larkin
On Mon, Jan 02, 2023 at 05:52:12PM +, Peter Stuge wrote: > Mark Kettenis wrote: > > patrick@, mlarkin@, yasuoka@ and other devs: ok? > > Do what you have to do, but I plead to avoid (U)EFI lock-in as far as > technically possible, since most (U)EFI implementations are not open > source, and

Re: vmt.c: Change space character to TAB

2022-12-27 Thread Mike Larkin
On Wed, Dec 28, 2022 at 03:36:56PM +0900, Masato Asou wrote: > ok? > > -- > ASOU Masato ok mlarkin > > Index: sys/dev/pv/vmt.c > === > RCS file: /cvs/src/sys/dev/pv/vmt.c,v > retrieving revision 1.28 > diff -u -p -r1.28 vmt.c >

Re: Machine after unhibernate *sometimes* won't suspend/hibernate again or dim screen

2022-12-26 Thread Mike Larkin
On Sun, Dec 25, 2022 at 11:57:24PM -0600, Abel Abraham Camarillo Ojeda wrote: > # apmd -d > battery status: high. external power status: not connected. estimated > battery life 97% (223 minutes life time estimate) > can't disable driver messages, error: Inappropriate ioctl for device > apmevent

Re: Machine after unhibernate *sometimes* won't suspend/hibernate again or dim screen

2022-12-26 Thread Mike Larkin
On Mon, Dec 26, 2022 at 12:51:05AM -0600, Abel Abraham Camarillo Ojeda wrote: > On Mon, Dec 26, 2022 at 12:08 AM Mike Larkin wrote: > > > On Sun, Dec 25, 2022 at 11:39:29PM -0600, Abel Abraham Camarillo Ojeda > > wrote: > > > On Sun, Dec 25, 2022 at

Re: Machine after unhibernate *sometimes* won't suspend/hibernate again or dim screen

2022-12-25 Thread Mike Larkin
On Sun, Dec 25, 2022 at 11:39:29PM -0600, Abel Abraham Camarillo Ojeda wrote: > On Sun, Dec 25, 2022 at 9:46 PM Mike Larkin wrote: > > > On Fri, Dec 23, 2022 at 03:13:53PM -0600, Abel Abraham Camarillo Ojeda > > wrote: > > > On Fri, Dec 23, 2022 at 2:46 PM A

Re: Machine after unhibernate *sometimes* won't suspend/hibernate again or dim screen

2022-12-25 Thread Mike Larkin
On Fri, Dec 23, 2022 at 03:13:53PM -0600, Abel Abraham Camarillo Ojeda wrote: > On Fri, Dec 23, 2022 at 2:46 PM Abel Abraham Camarillo Ojeda < > acam...@verlet.org> wrote: > > > Forgot to mention I don't think this is a regression, just started to use > > hibernate/unhibernate more often lately.

Re: pvbus: pass M_ZERO properly

2022-12-07 Thread Mike Larkin
On Thu, Dec 08, 2022 at 11:35:33AM +0900, YASUOKA Masahiko wrote: > This is obvious. M_ZERO must be for 3rd argument. > > ok? > > Index: sys/dev/pv/pvbus.c > === > RCS file: /cvs/src/sys/dev/pv/pvbus.c,v > retrieving revision 1.25

Re: riscv64: print SBI vendor/version

2022-12-05 Thread Mike Larkin
On Sat, Dec 03, 2022 at 11:48:16PM +0100, Jeremie Courreges-Anglas wrote: > > With the diff below we get more details about the SBI version running on > the machine. My Unmatched machine has OpenBSD version 0.9 but upstream > has released 1.1 since, it implements v0.2 of the SBI spec but 0.3 and

Re: riscv64: use evcount_percpu(9) for clock interrupts

2022-12-05 Thread Mike Larkin
On Sat, Dec 03, 2022 at 01:15:09AM +0100, Jeremie Courreges-Anglas wrote: > > ok? > > Probably needs cheloha@'s ok but this looks ok to me. -ml > Index: clock.c > === > RCS file: /cvs/src/sys/arch/riscv64/riscv64/clock.c,v >

Re: riscv64: drop unused WEAK_REFERENCE macro

2022-12-05 Thread Mike Larkin
On Sat, Dec 03, 2022 at 12:16:43AM +0100, Jeremie Courreges-Anglas wrote: > > WEAK_REFERENCE seems to come from FreeBSD, it's not used in our tree. > (WEAK_ALIAS is defined a few lines above). > > ok? > ok mlarkin if you didnt get to it already > > Index: sys/arch/riscv64/include/asm.h >

Re: AMD pcidevs updates

2022-12-02 Thread Mike Larkin
On Fri, Dec 02, 2022 at 07:10:43PM +1100, Jonathan Gray wrote: > On Wed, Nov 30, 2022 at 07:57:33AM +, Laurence Tratt wrote: > > On Tue, Nov 29, 2022 at 10:42:36PM +, Laurence Tratt wrote: > > > > > The diff below adds some newish AMD elements to pcidevs. > &

Re: vmd: fix booting 7.2 ramdisks with >= 4G mem

2022-11-28 Thread Mike Larkin
On Mon, Nov 28, 2022 at 11:32:32AM -0500, Dave Voutila wrote: > tech@ et. al., > > When kettenis@ introduced a newer version of BOOTARG_CONSDEV to add > additional params for the AMD Ryzen V1000 family, vmd's code that > configures bootargs to support direct booting a ramdisk kernel didn't >

Re: Get rid of UVM_VNODE_CANPERSIST

2022-11-15 Thread Mike Larkin
On Tue, Nov 15, 2022 at 02:31:27PM +0100, Martin Pieuchot wrote: > UVM vnode objects include a reference count to keep track of the number > of processes that have the corresponding pages mapped in their VM space. > > When the last process referencing a given library or executable dies, > the

vmm(4): remove locking in vm_intr_pending

2022-11-08 Thread Mike Larkin
This lock/unlock around an atomic operation was causing delays delivering interupts into VMs. Pointed out by claudio@ when he ran md5 - in a VM and it became very sluggish. Debugging help from dlg and mpi, thanks. ok? -ml Index: arch/amd64/amd64/vmm.c

Re: Mark sched_yield(2) as NOLOCK

2022-11-08 Thread Mike Larkin
On Tue, Nov 08, 2022 at 01:14:02PM +, Martin Pieuchot wrote: > Now that mmap/munmap/mprotect(2) are no longer creating contention it is > possible to see that sched_yield(2) is one of the syscalls waiting for > the KERNEL_LOCK() to be released. However this is no longer necessary. > >

Re: tc_setclock: don't print warning when tc_windup() rejects RTC time

2022-11-08 Thread Mike Larkin
On Tue, Nov 08, 2022 at 11:59:17AM +, Scott Cheloha wrote: > On some arm64 machines, the agtimer(4) ticks slowly enough that the > tc_delta() doesn't overflow across brief suspends. While working on > arm64 suspend/resume, kettenis@ has been seeing warnings like this > during resume: > >

Re: Please test: unlock mprotect/mmap/munmap

2022-11-06 Thread Mike Larkin
On Sun, Nov 06, 2022 at 11:54:13AM +0100, Martin Pieuchot wrote: > These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This > will reduce contention a lot. I'd be happy to hear from test reports > on many architectures and possible workloads. > > Do not forget to run "make syscalls"

Re: ThinkPad X13s and OpenBSD

2022-10-07 Thread Mike Larkin
On Fri, Oct 07, 2022 at 11:59:49AM -0700, Bryan Vyhmeister wrote: > Hey Patrick, > > I hope you're doing well. We have not talked in quite a while. I was > wondering how well the support for the ThinkPad X13s works right now in > OpenBSD. I did some searching around and couldn't find much other

Re: vmd: remove the user quota tracking

2022-10-05 Thread Mike Larkin
On Wed, Oct 05, 2022 at 05:03:16PM -0400, Dave Voutila wrote: > Matthew Martin recently presented a patch on tech@ [1] fixing some missed > scaling from when I converted vmd(8) to use bytes instead of megabytes > everywhere. I finally found time to wade through the code it touches and > am

Re: [please test] tsc: derive frequency on AMD CPUs from MSRs

2022-09-23 Thread Mike Larkin
On Sat, Sep 24, 2022 at 11:06:24AM +1000, Jonathan Gray wrote: > On Fri, Sep 23, 2022 at 09:16:25AM -0500, Scott Cheloha wrote: > > Hi, > > > > TL;DR: > > > > I want to compute the TSC frequency on AMD CPUs using the methods laid > > out in the AMD manuals instead of calibrating the TSC by hand. >

Re: Help on helping with virtualization?

2022-09-22 Thread Mike Larkin
On Wed, Sep 21, 2022 at 08:09:05AM -0400, Christoff Humphries wrote: > Hello. > > I want to help with the virtualization project to get the things that are > incomplete or missing completed (ie, the "not available at this time" list > on https://www.openbsd.org/faq/faq16.html). Great, always nice

Re: Towards unlocking mmap(2) & munmap(2)

2022-09-14 Thread Mike Larkin
On Sun, Sep 11, 2022 at 12:26:31PM +0200, Martin Pieuchot wrote: > Diff below adds a minimalist set of assertions to ensure proper locks > are held in uvm_mapanon() and uvm_unmap_remove() which are the guts of > mmap(2) for anons and munmap(2). > > Please test it with WITNESS enabled and report

Re: [please test] pvclock(4): fix several bugs

2022-09-08 Thread Mike Larkin
On Thu, Sep 08, 2022 at 08:32:27AM -0500, Scott Cheloha wrote: > On Tue, Sep 06, 2022 at 03:30:44AM -0700, Mike Larkin wrote: > > On Sun, Sep 04, 2022 at 02:50:10PM +1000, Jonathan Gray wrote: > > > On Sat, Sep 03, 2022 at 05:33:01PM -0500, Scott Cheloha wrote: > > > &

Re: [please test] pvclock(4): fix several bugs

2022-09-06 Thread Mike Larkin
On Sun, Sep 04, 2022 at 02:50:10PM +1000, Jonathan Gray wrote: > On Sat, Sep 03, 2022 at 05:33:01PM -0500, Scott Cheloha wrote: > > On Sat, Sep 03, 2022 at 10:37:31PM +1000, Jonathan Gray wrote: > > > On Sat, Sep 03, 2022 at 06:52:20AM -0500, Scott Cheloha wrote: > > > > > On Sep 3, 2022, at

Re: [please test] pvclock(4): fix several bugs

2022-09-03 Thread Mike Larkin
On Fri, Sep 02, 2022 at 06:00:25PM -0500, Scott Cheloha wrote: > dv@ suggested coming to the list to request testing for the pvclock(4) > driver. Attached is a patch that corrects several bugs. Most of > these changes will only matter in the non-TSC_STABLE case on a > multiprocessor VM. > >

Re: vmd(8): compute i8254 Read-Back latch from singular timestamp

2022-09-02 Thread Mike Larkin
On Fri, Sep 02, 2022 at 11:42:03AM -0500, Scott Cheloha wrote: > The 8254 data sheet [1] says this about the Read-Back command: > > > The read-back command may be used to latch multi- > > ple counter output latches (OL) by setting the > > COUNT bit D5 = 0 and selecting the desired coun- > >

Re: vmd(8): compute i8254 Read-Back latch from singular timestamp

2022-09-02 Thread Mike Larkin
On Fri, Sep 02, 2022 at 11:42:03AM -0500, Scott Cheloha wrote: > The 8254 data sheet [1] says this about the Read-Back command: > > > The read-back command may be used to latch multi- > > ple counter output latches (OL) by setting the > > COUNT bit D5 = 0 and selecting the desired coun- > >

Re: i386/lapic.c: sync with amd64/lapic.c

2022-08-30 Thread Mike Larkin
On Sun, Aug 28, 2022 at 03:26:49PM -0500, Scott Cheloha wrote: > As promised off-list: in anticipation of merging the clock interrupt > code, let's sync up the lapic timer parts of i386/lapic.c with the > corresponding parts in amd64/lapic.c. They will need identical > changes to use the new

Re: stub out initial mmio support for vmm(4)/vmd(8)

2022-08-30 Thread Mike Larkin
(see below) On Mon, Aug 15, 2022 at 03:06:05PM -0400, Dave Voutila wrote: > > Mike Larkin writes: > > > On Fri, Jul 15, 2022 at 12:27:04PM -0400, Dave Voutila wrote: > >> The following diff adds in formalization around mmio assists for nested > >> page/ept fau

Re: uvmpd_dropswap()

2022-08-29 Thread Mike Larkin
On Mon, Aug 29, 2022 at 01:58:38PM +0200, Martin Pieuchot wrote: > Small refactoring to introduce uvmpd_dropswap(). This will make an > upcoming rewrite of the pdaemon smaller & easier to review :o) > > ok? > reads ok to me. ok mlarkin > Index: uvm/uvm_pdaemon.c >

Re: use libkern bzero on i386

2022-08-21 Thread Mike Larkin
On Mon, Aug 22, 2022 at 12:31:45AM +1000, Jonathan Gray wrote: > libkern bzero doesn't have the 486 path but is otherwise the same > ok mlarkin (but didnt test) > diff --git sys/arch/i386/i386/locore.s sys/arch/i386/i386/locore.s > index dba6ce75b81..3055a06812c 100644 > ---

Re: regress: vmd: disable on i386

2022-08-21 Thread Mike Larkin
On Sat, Aug 20, 2022 at 09:03:59AM +, Klemens Nanni wrote: > vmd/Makefile filters for amd64 itself but still, no need to enter > on !amd64. > > Index: ../Makefile > === > RCS file: /cvs/src/regress/usr.sbin/Makefile,v > retrieving

Re: remove support for Cyrix 486DLC & Cyrix 6x86

2022-08-19 Thread Mike Larkin
On Fri, Aug 19, 2022 at 10:31:30PM -0400, Daniel Dickman wrote: > The below diff removes detection code for the Cyrix 486DLC and Cyrix 6x86 > CPUs from OpenBSD/i386. > > The Cyrix 486DLC is a 486-class CPU which we no longer support. > > The 6x86, also known as the M1, does not support CPUID by

Re: Fix a race in uvm_pseg_release()

2022-08-18 Thread Mike Larkin
On Thu, Aug 18, 2022 at 12:39:58PM +0200, Martin Pieuchot wrote: > The lock must be grabbed before iterating on the global array, ok? > > Index: uvm/uvm_pager.c > === > RCS file: /cvs/src/sys/uvm/uvm_pager.c,v > retrieving revision

Re: [RFC] acpi: add acpitimer_delay(), acpihpet_delay()

2022-08-18 Thread Mike Larkin
On Wed, Aug 17, 2022 at 09:00:12PM +1000, Jonathan Gray wrote: > On Wed, Aug 17, 2022 at 04:53:20PM +1000, Jonathan Gray wrote: > > > > It seems to me it would be cleaner if the decision of what to use for > > delay could be moved into an md file. > > > > Or abstract it by having a numeric weight

Re: fix i386 cpu classnames

2022-08-17 Thread Mike Larkin
On Wed, Aug 17, 2022 at 03:27:51PM +1000, Jonathan Gray wrote: > broken after rev 1.652 of machdep.c > > cpu0: Intel(R) Pentium(R) M processor 1200MHz ("GenuineIntel" 686-class) 1.20 > GHz, 06-09-05 > cpu0: Intel(R) Pentium(R) M processor 1200MHz ("GenuineIntel" -class) 1.20 > GHz, 06-09-05 > >

Re: [RFC] acpi: add acpitimer_delay(), acpihpet_delay()

2022-08-15 Thread Mike Larkin
On Sun, Aug 14, 2022 at 11:24:37PM -0500, Scott Cheloha wrote: > Hi, > > In the future when the LAPIC timer is run in oneshot mode there will > be no lapic_delay(). > > This is fine if you have a constant TSC, because we have tsc_delay(). > > This is *very* bad for older amd64 machines, because

Re: remove pre-486 code from i386 platform

2022-07-28 Thread Mike Larkin
On Wed, Jul 27, 2022 at 10:18:55PM -0400, Daniel Dickman wrote: > The diff below removes support for 386SX/DX processors. We already claim > we don't support anything older than a Pentium so there's no point to keep > this code. > > The main code change is in locore0.S and is to stop checking if

Re: stub out initial mmio support for vmm(4)/vmd(8)

2022-07-26 Thread Mike Larkin
On Fri, Jul 15, 2022 at 12:27:04PM -0400, Dave Voutila wrote: > The following diff adds in formalization around mmio assists for nested > page/ept faults on Intel and AMD vmm(4) hosts. It provides what little > information is available to userland in terms of either the instruction > bytes (on

Re: remove rise detection from i386

2022-07-23 Thread Mike Larkin
On Sat, Jul 23, 2022 at 02:13:27PM -0400, Daniel Dickman wrote: > The Rise mp6 was a short lived processor that was announced around 20+ > years and didn't make it to market. > > I think we can delete the cpu identification for this cpu at this point. > > ok? ok mlarkin > > Index: i386/machdep.c

Re: [v3] amd64: simplify TSC sync testing

2022-07-06 Thread Mike Larkin
On Wed, Jul 06, 2022 at 11:48:41AM -0500, Scott Cheloha wrote: > > On Jul 6, 2022, at 11:36 AM, Mike Larkin wrote: > > > > On Tue, Jul 05, 2022 at 07:16:26PM -0500, Scott Cheloha wrote: > >> On Tue, Jul 05, 2022 at 01:38:32PM -0700, Mike Larkin wrote: > >>

Re: [v3] amd64: simplify TSC sync testing

2022-07-06 Thread Mike Larkin
On Tue, Jul 05, 2022 at 07:16:26PM -0500, Scott Cheloha wrote: > On Tue, Jul 05, 2022 at 01:38:32PM -0700, Mike Larkin wrote: > > On Mon, Jul 04, 2022 at 09:06:55PM -0500, Scott Cheloha wrote: > > > > > > [...] > > > > Here's the output from a 4 socket 8

Re: [v3] amd64: simplify TSC sync testing

2022-07-05 Thread Mike Larkin
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

Re: amdgpio(4) : preserve pin configuration on resume

2022-06-26 Thread Mike Larkin
On Wed, Apr 20, 2022 at 11:39:00AM +0200, Mark Kettenis wrote: > > Date: Tue, 19 Apr 2022 22:02:00 -0700 > > From: Mike Larkin > > > > On at least the Asus ROG Zephyrus 14 (2020), the trackpad fails to generate > > any interrupts after resume. I tracked this down to

Re: rewrite amd64 cache printing

2022-06-25 Thread Mike Larkin
On Fri, Jun 24, 2022 at 07:19:47PM +1000, Jonathan Gray wrote: > Rewrite amd64 printing of cache details. > Previously we looked at cpuid 0x8005 for L1/TLB details > which Intel documents as reserved. > And cpuid 0x8006 for L2 details. > > Intel also encode cache details in cpuid 4. > AMD

Re: Lenovo ThinkCentre M910q fails to suspend

2022-06-17 Thread Mike Larkin
On Fri, Jun 17, 2022 at 08:32:29PM +0100, Edd Barrett wrote: > Hi Mike, > > On Fri, Jun 17, 2022 at 11:55:51AM -0700, Mike Larkin wrote: > > > - disabling xhci in ukc: the system fails to boot multi-user. The first > > >oddness comes where cpus #1-3 fail to

Re: Lenovo ThinkCentre M910q fails to suspend

2022-06-17 Thread Mike Larkin
On Fri, Jun 17, 2022 at 06:41:23PM +0100, Edd Barrett wrote: > Hi Mike, > > On Fri, Jun 17, 2022 at 10:20:35AM -0700, Mike Larkin wrote: > > Oh, didn't read this closely enough the first time. If ZZZ doesn't > > instantly wake > > the machine, then it's one of the two S

Re: Lenovo ThinkCentre M910q fails to suspend

2022-06-17 Thread Mike Larkin
On Fri, Jun 17, 2022 at 09:14:45AM +0100, Edd Barrett wrote: > Hi Mike, > > On Thu, Jun 16, 2022 at 09:19:50PM -0700, Mike Larkin wrote: > > From your original dmesg: > > > > > acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) > > > PEGP

Re: Lenovo ThinkCentre M910q fails to suspend

2022-06-17 Thread Mike Larkin
On Fri, Jun 17, 2022 at 09:14:45AM +0100, Edd Barrett wrote: > Hi Mike, > > On Thu, Jun 16, 2022 at 09:19:50PM -0700, Mike Larkin wrote: > > From your original dmesg: > > > > > acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) > > > PEGP

Re: Lenovo ThinkCentre M910q fails to suspend

2022-06-16 Thread Mike Larkin
On Thu, Jun 16, 2022 at 08:48:36PM +0100, Edd Barrett wrote: > On Thu, Jun 16, 2022 at 10:22:16AM -0700, Mike Larkin wrote: > > did it ever work in the past? > > I've only just received the machine, so it's difficult to say. > > I've spent the last hour changing various

Re: Lenovo ThinkCentre M910q fails to suspend

2022-06-16 Thread Mike Larkin
On Thu, Jun 16, 2022 at 05:14:53PM +0100, Edd Barrett wrote: > Hi, > > Has anyone managed to get a Lenovo ThinkCentre M910q (or similar) to suspend > with OpenBSD? > > When invoking `zzz` the system prepares to go down, the screen goes blank, but > then a short while later, the system comes back,

Re: Fix rebooting Linux guests in vmd(8)

2022-06-05 Thread Mike Larkin
On Sun, Jun 05, 2022 at 09:25:34AM -0400, Dave Voutila wrote: > tech@ friends: > > tl;dr: testers wanted for fixing Linux guest reboot. If you've got > Linux guests that no longer reboot properly, please test! For other > vmd users, please check for any regressions. > > Our port of SeaBIOS is

Re: vmm: remove vm teardown from vcpu run path (testers needed)

2022-06-05 Thread Mike Larkin
On Thu, Jun 02, 2022 at 03:05:16PM -0400, Dave Voutila wrote: > > Dave Voutila writes: > > > tech@ et al.: > > > > Looking for testers of the following diff for vmm(4). In my efforts to > > fix some stability issues, I'm taking baby steps tweaking parts of the > > code to make my upcoming

Re: move vmm(4) spinout paranoia behind MP_LOCKDEBUG

2022-05-20 Thread Mike Larkin
On Sat, Apr 16, 2022 at 12:09:46PM -0400, Dave Voutila wrote: > This tucks all the spinout paranoia behind `#ifdef MP_LOCKDEBUG` and > uses the same approach used in amd64's pmap's TLB shootdown code. > > Part of me wants to remove this altogether, but I'm not sure it's > outlived its usefulness

Re: vmm: load vmcs before reading vcpu registers

2022-05-20 Thread Mike Larkin
On Wed, May 18, 2022 at 10:27:11AM -0400, Dave Voutila wrote: > > ping...would like to get this in if possible so I can move onto fixing > some things in vmm. > sorry. ok mlarkin > Dave Voutila writes: > > > tech@, > > > > Continuing my vmm/vmd bug hunt, the following diff adapts > >

Re: Picky, but much more efficient arc4random_uniform!

2022-05-15 Thread Mike Larkin
On Sun, May 15, 2022 at 08:40:19PM -0500, Luke Small wrote: > https://marc.info/?l=openbsd-tech=165259528425835=2 > > This one (which is strongly based upon my first of two versions) which I > submitted after Guenther correctly trashed version 2, doesn’t reuse any > part of the sample. It picks up

Re: vmm: give a lonely enum a friend, fixing `vmctl receive`

2022-05-13 Thread Mike Larkin
On Sun, May 08, 2022 at 10:30:46PM -0400, Dave Voutila wrote: > tech@, > > Another vmm/vmd update: fix `vmctl receive` on Intel hosts by adding > another fault enum value to disambiguate fault reasons. > > It's expected that the guest will trigger nested page faults after being > received by vmd.

Re: vmd: fix rebooting a received vm

2022-05-07 Thread Mike Larkin
On Sat, May 07, 2022 at 07:58:15AM -0400, Dave Voutila wrote: > tech@: > > Now that vmd only accounts for memory in bytes [1], this fix is a lot > simpler! > > If you use the send/receive functionality and "receive" a sent vm, it > functions as expected. However, if that vm tries to reboot, it

Re: aml parse error

2022-05-03 Thread Mike Larkin
On Tue, May 03, 2022 at 04:46:55PM +0200, aphekz wrote: > On Mon, May 02, 2022 at 07:05:24PM -0700, Mike Larkin wrote: > > On Mon, May 02, 2022 at 11:42:57PM +0200, aphekz wrote: > > > > > > May 2 21:29:06 dev /bsd: ### AML PARSE ERROR (0x8f3a): Undefined name: >

Re: aml parse error

2022-05-02 Thread Mike Larkin
On Mon, May 02, 2022 at 11:42:57PM +0200, aphekz wrote: > > May 2 21:29:06 dev /bsd: ### AML PARSE ERROR (0x8f3a): Undefined name: OPST > May 2 21:29:06 dev /bsd: error evaluating: \\_SB_.PCI0.LPCB.EC0_._Q14 > May 2 21:29:55 dev /bsd: ### AML PARSE ERROR (0x8f3a): Undefined name: OPST > May 2

Re: migrate vmd/vmm/vmctl to use bytes, not MBs

2022-05-02 Thread Mike Larkin
On Mon, May 02, 2022 at 04:09:19PM -0400, Dave Voutila wrote: > > Dave Voutila writes: > > > tech@, > > > > tl;dr: standardize vmd/vmm/vmctl on counting memory in bytes at all > > times instead of a mix of MiB and bytes. > > > > There's some design friction between vmd(8)/vmctl(8) and vmm(4). > >

Re: DPTF sensors driver

2022-04-25 Thread Mike Larkin
On Sun, Apr 24, 2022 at 08:00:50PM -0500, joshua stein wrote: > Any interest in this? > > acpidptfs0 at acpi0: SEN2, sensor "Sensor 2 USB2" > acpidptfs1 at acpi0: SEN4, sensor "Sensor 4 Ambience" > acpidptfs2 at acpi0: SEN1, sensor "Thermistor CPU SOC" > acpidptfs3 at acpi0: SEN3, sensor "Sensor 3

Re: amdgpio(4) : preserve pin configuration on resume

2022-04-20 Thread Mike Larkin
On Wed, Apr 20, 2022 at 11:39:00AM +0200, Mark Kettenis wrote: > > Date: Tue, 19 Apr 2022 22:02:00 -0700 > > From: Mike Larkin > > > > On at least the Asus ROG Zephyrus 14 (2020), the trackpad fails to generate > > any interrupts after resume. I tracked this down to

amdgpio(4) : preserve pin configuration on resume

2022-04-19 Thread Mike Larkin
On at least the Asus ROG Zephyrus 14 (2020), the trackpad fails to generate any interrupts after resume. I tracked this down to amdgpio(4) not generating interrupts after resume, and started looking at missing soft state. This diff preserves the interrupt pin configurations and restores them

Re: vmd writes corrupt qcow2 images

2022-04-18 Thread Mike Larkin
On Mon, Apr 18, 2022 at 12:21:39PM -0400, Dave Voutila wrote: > > "Thomas L." writes: > > > Hi, > > > > I recently tried to use qemu-img with qcow2 images of my VMs and > > qemu-img finds them corrupted. I can reproduce the issue in the > > following way (on -current, but is the same on -stable;

Re: VMM avoid duplication and reduce atack surface with octboot(4)

2022-03-22 Thread Mike Larkin
On Wed, Mar 23, 2022 at 04:27:40AM +, Alexis wrote: > Indeed I understood both octboot and vmm seabios/uefi initialazation process. > > But has its done with kexec and linuxboot coreboot payload octboot could be > ported to act in the same way. Explaining now again for the 3rd time, to >

  1   2   3   4   5   6   7   >