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 i
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 event
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,
> >>>
> >>
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
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
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
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 afterno
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 strang
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:
> > > >
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:
> > >
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.
>
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 i8
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 v
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:
> >> > This
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
> > >
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: sys/dev/
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 GPROF
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
> ==
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 file
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 r
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
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 process
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, e
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
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. T
base. That is very relevant if you e.g. remove a line from /etc/sysctl.conf
(to go back to the default).
Mike
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 al
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
> ===
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.
>
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
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
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 resul
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 t
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
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
> pas
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 th
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
> ---
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 000
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 9:46 PM Mike Lark
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
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.
>
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
>
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
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
> retr
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
>
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.
> &
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
> adjust
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 reape
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
==
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.
>
> Traversi
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:
>
> tc_se
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" be
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 tha
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 proposin
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.
>
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
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 bac
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:
> > > &
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 02:22,
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.
>
> Ideal
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-
> > ter(s).
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-
> > ter(s).
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 code,
(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
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
> ===
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
> --- sys/arch/i386/i386/lo
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
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 def
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 1.8
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 l
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
>
> C
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 you
s production
facilities in Hamburg. Regular flights do not use XFW except possibly in the
case of serious emergencies.
Mike
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 th
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 AMD)
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
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:
> >>
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
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 th
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
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 h
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 &qu
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 o
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
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
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 chan
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, a
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 confi
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 proposal
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 qu
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
> > vcpu_readre
On Sun, May 15, 2022 at 08:40:19PM -0500, Luke Small wrote:
> https://marc.info/?l=openbsd-tech&m=165259528425835&w=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
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. W
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 caus
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:
>
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 2
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).
> >
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
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
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 after
1 - 100 of 1340 matches
Mail list logo
