Recently, I rewrote parts of the emulated virtio block device in vmd(8)
to fix issues found bringing up NetBSD as a guest. In the process, the
rewrite introduced the chance to do zero-copy transfers for raw block
devices. The diff below brings that design to the virtio network device.
In summary:
Klemens Nanni writes:
> On Sun, Oct 15, 2023 at 07:51:00AM -0400, Dave Voutila wrote:
>>
>> Dave Voutila writes:
>>
>> > Looking for folks that use the serial console connection in vmd(8) and
>> > experience the host CPU spikes & delays associat
Dave Voutila writes:
> Looking for folks that use the serial console connection in vmd(8) and
> experience the host CPU spikes & delays associated with things like
> hitting the up key (to cycle shell command history) or copy/paste in X.
>
> vmd(8) approximates edge t
Looking for folks that use the serial console connection in vmd(8) and
experience the host CPU spikes & delays associated with things like
hitting the up key (to cycle shell command history) or copy/paste in X.
vmd(8) approximates edge triggered interrupts with the emulated i8259
interrupt
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 thread is trying to
assert an irq, it will try to lock that "run"
It annoys me how all the log messages from different vmd vm's blur
together. Here is a diff that makes them distinguishable. It also fixes
dynamic toggling of verbosity levels in virtio devices using `vmctl
log`, and now preserves the verbosity across vm reboots.
I chose the pattern "vm/ and
Mischa writes:
> On 2023-09-06 05:36, Dave Voutila wrote:
>> Mischa writes:
>>> On 2023-09-05 14:27, Dave Voutila wrote:
>>>> Mike Larkin writes:
>>>>
>>>>> On Mon, Sep 04, 2023 at 07:57:18PM +0200, Mischa wrote:
>>>>>&
Mischa writes:
> On 2023-09-05 14:27, Dave Voutila wrote:
>> Mike Larkin writes:
>>
>>> 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:
>> /snip
&
Mike Larkin writes:
> 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:
/snip
>> > > Adding the sleep 2 does indeed help. I managed to get 20 VMs started
>> > > this way, before it would choke on 2-3.
>> > >
Mischa writes:
> On 2023-09-04 16:23, Mike Larkin wrote:
>> 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!
>>> > &g
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 afternoon (4 Sep) my time
unless I hear of any issues.
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 strange configurations can give it a spin.
This change removes an ioctl(2)
Dave Voutila writes:
> mbuhl@ found an issue where the emulated virtio block device can
> hang. The tl;dr: the emulated pic never injects an interrupt and the
> vioblk(4) driver in the guest starves, waiting to be told to check the
> virtqueue.
>
> Flipping the bit in t
mbuhl@ found an issue where the emulated virtio block device can
hang. The tl;dr: the emulated pic never injects an interrupt and the
vioblk(4) driver in the guest starves, waiting to be told to check the
virtqueue.
Flipping the bit in the i8259 using gdb causes the spice to flow once
again.
Claudio Jeker writes:
> On Thu, Aug 03, 2023 at 07:01:51PM -0400, Dave Voutila wrote:
>>
>> Claudio Jeker writes:
>>
>> > On Thu, Aug 03, 2023 at 04:20:47PM -0400, Dave Voutila wrote:
>> >> Found this while working on some virtio stuff. My original
Claudio Jeker writes:
> On Thu, Aug 03, 2023 at 04:20:47PM -0400, Dave Voutila wrote:
>> Found this while working on some virtio stuff. My original
>> implementation as part of the multi-process redesign didn't handle if
>> imsg_flush failed due to resource shortag
Found this while working on some virtio stuff. My original
implementation as part of the multi-process redesign didn't handle if
imsg_flush failed due to resource shortages (EAGAIN), so adopt the
do/while idiom used by other daemons like iked(8).
Manifests with errors from the vm process looking
While hunting a perf issue with vmd's vioblk emulation, stumbled upon
some virtio drivers initializing function pointers to 0 for their config
change handlers. Switch to using NULL for better semantic fit.
ok?
diff refs/heads/master refs/heads/virtio
commit -
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 very chatty debug message related to ipc with devices.
This doesn't
Solène Rapenne writes:
> On Fri, 2023-06-09 at 11:25 -0400, Dave Voutila wrote:
>>
>> Thanks. This feels like bad fd accounting during the fork/exec dance.
>>
>> Sounds like the switch definition and usage isn't required for
>> reproducing?
>
> indee
vmd's doing something close to shotgun parsing of the "local prefix" and
"local inet6 prefix" settings in vm.conf(5). The parser intermixes ipv4
and ipv6 parsing even when we know which one is valid in the parsing
context. This makes me sad.
Even worse, we're not validating the inputs at time of
Jasper Lievisse Adriaanse writes:
> Hi,
>
> It seems there is an inconsistency when it comes to terminating a VM by
> id or name (4/web point to the same VM here):
>
> before:
> % vmctl stop 4
> stopping vm: requested to shutdown vm 4
> % vmctl stop web
> stopping vm web: failed: Invalid
Omar Polo writes:
> Hello,
>
> after vmd.c rv 1.142 vmd(8) errors when ran with a non-absolute path;
> this makes using -n (configtest) slightly more verbose, as the full
> path is needed and not just `vmd -n'.
>
> here's an attempt at relaxing the requirement for the -n case only.
> since
Solène Rapenne writes:
> I'm currently playing with derived qcow2 disks using vmd. While my
> setup was working on 7.3 (maybe there is an issue with MAC assignments
> in VMs) so I updated to current, but now VMs don't start at all when
> they are using a derived qcow2 disk + network interface
As mentioned before on bugs@ [1], the custom local prefix feature of vmd
broke with some of the recent changes. Since fixing this touches a lot
of parts of vmd, I'm breaking it up to make it reviewable by others and
hopefully less daunting.
This diff fixes an existing issue (predating recent
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.
Similar to the vm creation ioctl (VMM_IOC_CREATE), the caller
The diff below adapts the way vmctl & vmd handle opening kernel images
when a vmctl user provides the -b argument and a path. This moves the
file opening into vmctl, as the current user, and passes the fd to vmd.
With some tweaks, it checks for this user-provided boot fd and uses it
as an
Dave Voutila writes:
> tech@:
>
> The below diff splits out virtio device emulation for virtio block and
> network devices into separate fork+exec'd & pledge(2)'d subprocesses.
>
> In order of priority, this diff:
>
> 1. Isolates common exploit targets (e.g. em
file->close = qc2_close;
- *szp = diskp->disksz;
+ *szp = diskp->disksz / 512;
return 0;
}
blob - /dev/null
blob + 5ecf349292482d03433761352cbc9ec91b695bc1 (mode 644)
--- /dev/null
+++ usr.sbin/vmd/vioblk.c
@@ -0,0 +1,1011 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2023 Dave Voutila
+ * Copyri
Klemens Nanni writes:
> 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 fixed the same for dhcpleased a year ago,
ping
Dave Voutila writes:
> 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 tha
tech@,
vmd currently uses a fork-only approach to spawning new vm's, resulting
in each vm having the same address space and inheriting some global
state from the vmm process (like the list of running vm's). This diff
introduces an execvp(2) call after fork, making the vm process re-exec.
Things
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 that forks vm's.
This NULL's out the hva to and resets it on
Philip Guenther writes:
> On Fri, Apr 7, 2023 at 9:44 AM Dave Voutila wrote:
> ...
>
> Touch longer, but won't generate ktrace noise by blind calls to close(2)
> and also accounts for the other error conditions (EINTR, EIO).
>
> For EIO, not sure yet how we want to han
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, etc.).
>
> The logic was a bit funky, so this change rel
"Theo de Raadt" writes:
> Florian Obser wrote:
>
>> On 2023-04-07 10:51 -04, Dave Voutila wrote:
>> > In vmd, the vmm process forks to create the resulting vm process. After
>> > this fork, the vmm parent process closes all the file descriptors
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, etc.).
The logic was a bit funky, so this change relies on the fact we can
attempt the close(2) call
Stuart Henderson writes:
> On 2023/04/06 15:49, Klemens Nanni wrote:
>> bios0: vendor SeaBIOS version
>> "1.14.0-20230330_133212-symphytum.spacehopper.orgp2-OpenBSD-vmm" date
>> 01/01/2011
>>
>> in dmesg is a weird concat of port version, datetime, hostname,
>> port revision, uname(?) and a
Crystal Kolipe writes:
> We currently don't implement the /dev/full device, which is present in
> NetBSD, FreeBSD, and Linux.
>
> For those who haven't heard of it, it's basically the same as /dev/zero, but
> writes to it always return ENOSPC.
>
> The lack of /dev/full on OpenBSD has
"Brian Conway" writes:
> Greetings. I am soliciting feedback on a patch to detect and mitigate
> uncontrolled ACPI GPE interrupt storms.
>
> Rationale: There have been a number of threads in the recent past on bugs@
> and misc@ with acpi0 spinning a CPU at 100% [1][2][3][4]. The immediate
joshua stein writes:
> Revision 1.67 made acpithinkpad not take over screen backlight
> control and let inteldrm or some other driver handle it. This was
> done to support fine-grained levels of backlight control rather than
> the dozen steps that the native EC interface supports.
>
>
Mark Kettenis writes:
>> From: Dave Voutila
>> Date: Sun, 12 Feb 2023 12:47:56 -0500
>>
>> Noticed on my X1 Carbon gen10 that ichiic(4) complains about a timeout
>> while doing a bus scan as part of attach. Traced it down to the fact we
>> forc
Noticed on my X1 Carbon gen10 that ichiic(4) complains about a timeout
while doing a bus scan as part of attach. Traced it down to the fact we
force polling if the global cold==1 even if the device reports
supporting interrupts. This fixes the issue and lets the bus scan
complete without error.
And I should have prefaced this with: the reason we have to use PKU is
because it's the only way we can get a read-deny bit on Intel, that
still allows instruction fetches. Otherwise, PROT_EXEC implies PROT_READ.
Dave Voutila writes:
> Marc Espie writes:
>
>> I'm curious a
Marc Espie writes:
> I'm curious about the new enforcement strategies. Unfortunately I'm a bit
> lost in the 1000+ pages of the intel manual.
The protection keys documentation is thin because it's just another
layer in the rules for paging. I'll try to summarize and I'm sure
someone will
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 guest inside OpenBSD vmm atop Linux KVM. I don't know
enough about how
*bump*... Anyone able to test or review? Other than bikeshedding some
function naming, this isn't a dramatic change.
Dave Voutila writes:
> Dave Voutila writes:
>
>> It turns out not only does vmd have numerous error paths for handling
>> when something is amiss
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 hook in via
comparing the FirmwareVendor "string" to make sure we're
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 result, vmd often removes the vm from the SLIST of vm's mean
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 result, vmd often removes the vm from the SLIST of vm's meaning
one can't easily attempt to start it again or see
Dave Voutila writes:
> During h2k22 there was some discussion around how vmd(8) manages vms and
> the vmm(4) device's role. While looking into something related, I found
> vmd opens /dev/vmm in each subprocess during the initial fork+execve
> dance.
>
> The only vmd process t
Christian Ludwig writes:
> [[S/MIME Signed Part:Undecided]]
> The vmm(4) ioctl handler unlocks the kernel, but misses to relock it in
> case of an error.
Thanks! Committed.
> ---
> sys/arch/amd64/amd64/vmm.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git
Mike Larkin writes:
> 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
&g
This ok with folks? Had OK's for the original diff but double checking
before I commit.
Dave Voutila writes:
> Philip Guenther writes:
>
>> On Sat, Jan 7, 2023 at 11:04 AM Dave Voutila wrote:
>>
>> Bringing this to tech@ to increase my chance of som
Philip Guenther writes:
> On Sat, Jan 7, 2023 at 11:04 AM Dave Voutila wrote:
>
> Bringing this to tech@ to increase my chance of someone testing my
> diff.
>
> As reported in this thread on misc@ [1], I believe newer Intel hardware
> may be experiencing issues hosti
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 the vcpu thread.
Example ps output:
$ ps -AHf | grep vmd
30584 502984 p2 S+p 0:00.76 | |-- obj/vmd -d
46975 512305 ?? Sc
Bringing this to tech@ to increase my chance of someone testing my
diff.
As reported in this thread on misc@ [1], I believe newer Intel hardware
may be experiencing issues hosting Linux guests under vmm/vmd. It looks
like there are some newer instructions Intel added (TPAUSE specifically)
that
During h2k22 there was some discussion around how vmd(8) manages vms and
the vmm(4) device's role. While looking into something related, I found
vmd opens /dev/vmm in each subprocess during the initial fork+execve
dance.
The only vmd process that needs /dev/vmm is the vmm process.
The diff below
Dave Voutila writes:
> While working back and forth with dlg@ on his idea of adding in async
> task queues to vmd devices, he started to introduce a cleaner way to
> handle virtqueues. In short, we can just track the host virtual address
> and read/write to that location.
While working back and forth with dlg@ on his idea of adding in async
task queues to vmd devices, he started to introduce a cleaner way to
handle virtqueues. In short, we can just track the host virtual address
and read/write to that location.
This has the benefit of cleaning up a good chunk of
*bump*... now looking for OKs!
Dave Voutila writes:
> Dave Voutila writes:
>
>> tech@,
>>
>> The below diff tweaks how vmd and vmm define memory ranges (adding a
>> "type" attribute) so we can properly build an e820 memory map to hand to
>> thi
Mischa writes:
> On 2022-12-13 20:29, Dave Voutila wrote:
>> Dave Voutila writes:
>>
>>> tech@,
>>> The below diff tweaks how vmd and vmm define memory ranges (adding
>>> a
>>> "type" attribute) so we can properly build an e820 mem
Dave Voutila writes:
> tech@,
>
> The below diff tweaks how vmd and vmm define memory ranges (adding a
> "type" attribute) so we can properly build an e820 memory map to hand to
> things like SeaBIOS or the OpenBSD ramdisk kernel (when direct booting
> bsd.rd
Mischa writes:
> On 2022-12-12 16:36, Dave Voutila wrote:
>> Mischa writes:
>>
>>> On 2022-12-12 16:02, Dave Voutila wrote:
>>>> Mischa writes:
>>>>
>>>>> Hi Dave,
>>>>> Great stuff!!
>>>>> Everyt
Mischa writes:
> On 2022-12-12 16:02, Dave Voutila wrote:
>> Mischa writes:
>>
>>> Hi Dave,
>>> Great stuff!!
>>> Everything is patched, build and booted.
>>> What is the best way to test this?
>> Start guests as usual. I'
t; Mischa
>
> On 2022-12-10 23:51, Dave Voutila wrote:
>> tech@,
>> The below diff tweaks how vmd and vmm define memory ranges (adding a
>> "type" attribute) so we can properly build an e820 memory map to
>> hand to
>> things like SeaBIOS or the Open
tech@,
The below diff tweaks how vmd and vmm define memory ranges (adding a
"type" attribute) so we can properly build an e820 memory map to hand to
things like SeaBIOS or the OpenBSD ramdisk kernel (when direct booting
bsd.rd).
Why do it? We've been carrying a few patches to SeaBIOS in the
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 with it.
Mischa Peters found this and shared a simple reproducer on
Visa Hankala writes:
> On Fri, Nov 18, 2022 at 11:03:06AM -0500, Dave Voutila wrote:
>> That fixes booting and the Surface Keyboard is usable, but I'm getting
>> spurious faults coming from retpoline out of filt_wseventdetach if I
>> detach and reattach the Surface Ke
Mike Larkin writes:
> 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?
>
ok dv@. This is overly defensive
Matthew Martin writes:
> On Wed, Oct 12, 2022 at 09:20:06AM -0400, Dave Voutila wrote:
>>
>> 1 week bump for the below. If you use this feature or currently hacking
>> on it, speak up by end of week. I'm sharpening my axes.
>
> Are the axes sharp?
>
Thanks for the ping. Committed now.
-dv
1 week bump for the below. If you use this feature or currently hacking
on it, speak up by end of week. I'm sharpening my axes.
Dave Voutila writes:
> Matthew Martin recently presented a patch on tech@ [1] fixing some missed
> scaling from when I converted vmd(8) to use bytes i
Mark Kettenis writes:
> Here is a diff that implements EFI runtime services support on amd64
> in much the same way as we already do on arm64. This will be used in
> the future to implement support for EFI variables.
>
> Some initial testing among OpenBSD developers did not uncover any
>
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 proposing we simply "tedu" the incomplete feature.
Does anyone use this?
Matthew Martin writes:
> When vmd/vmctl switched to handling memory in bytes, seems a few places
> for user VMs were missed. Additionally the first hunk removes the quota
> hit if the VM will not be created.
>
Thanks, I'll take a deeper look this week. I don't use the user quota
pieces, so
Mike Larkin writes:
> 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
Scott Cheloha writes:
> 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). This single command is functionally
Ricardo Mestre writes:
> After discussing with martijn@ if we should keep using unveil(2) (or not), in
> his latest diff of further privsep'ing snmpd(8), and also after he also spoke
> with deraadt@, it turns out that unix's promise in pledge(2) is not enforcing
> the unix socket's file
Klemens Nanni writes:
> vmd/Makefile filters for amd64 itself but still, no need to enter
> on !amd64.
>
ok dv@.
> Index: ../Makefile
> ===
> RCS file: /cvs/src/regress/usr.sbin/Makefile,v
> retrieving revision 1.26
> diff -u -p
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 faults on Intel and AMD vmm(4) hosts. It provides what little
>> information is available to userla
enh writes:
> is there a CVE or PoC for the zlib bug? it seems like OpenBSD is the
> only place where this has been fixed, and none of the various
> upstreams/forks of zlib (of which there are far too many!) seem to
> have this?
>
See upstream:
Scott Cheloha writes:
> Hi,
>
> At the urging of sthen@ and dv@, here is v5.
>
> Two major changes from v4:
>
> - Add the function tc_reset_quality() to kern_tc.c and use it
> to lower the quality of the TSC timecounter if we fail the
> sync test.
>
> tc_reset_quality() will choose a new
Klemens Nanni writes:
> Do not silently ignore additional arguments:
>
> $ vmctl create
> usage: vmctl [-v] create [-b base | -i disk] [-s size] disk
> $ vmctl create -s 1G 1.img 2.img
> vmctl: raw imagefile created
> $ ls *.img
> 1.img
>
> $
Mark Kettenis writes:
>> From: Dave Voutila
>> Date: Fri, 29 Jul 2022 10:51:20 -0400
>>
>> Mark Kettenis writes:
>>
>> >> From: Dave Voutila
>> >> Date: Fri, 29 Jul 2022 10:10:01 -0400
>> >>
>> >> Scott Cheloha
Mark Kettenis writes:
>> From: Dave Voutila
>> Date: Fri, 29 Jul 2022 10:10:01 -0400
>>
>> Scott Cheloha writes:
>>
>> > On Thu, Jul 28, 2022 at 04:57:41PM -0400, Dave Voutila wrote:
>> >>
>> >> Stuart Henderson writes:
>>
Scott Cheloha writes:
> On Thu, Jul 28, 2022 at 04:57:41PM -0400, Dave Voutila wrote:
>>
>> Stuart Henderson writes:
>>
>> > On 2022/07/28 12:57, Scott Cheloha wrote:
>> >> On Thu, Jul 28, 2022 at 07:55:40AM -0400, Dave Voutila wrote:
>> >
Stuart Henderson writes:
> On 2022/07/28 12:57, Scott Cheloha wrote:
>> On Thu, Jul 28, 2022 at 07:55:40AM -0400, Dave Voutila wrote:
>> >
>> > This is breaking timecounter selection on my x13 Ryzen 5 Pro laptop
>> > running the latest kernel from snaps.
Scott Cheloha writes:
> Hi,
>
> Thanks to everyone who tested v3.
>
> Attached is v4. I would like to put this into snaps (bcc: deraadt@).
>
> If you've been following along and testing these patches, feel free to
> continue testing. If your results change from v3 to v4, please reply
> with
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) or the instruction length (on Intel).
vmd is updated to intercept
Florian Obser writes:
> On 2022-07-12 14:35 +02, Florian Obser wrote:
>> When the autoconf flag flaps around we might end up with multiple bpf
>> FDs in flight. Things then get confusing. The kernel tells us we can
>> read from the bpf FD but the data is actually "on the other FD", so
>>
Mario Marietto writes:
> *Hello.*
>
> *I would like to know what's the status of the PCI passthrough on OpenBSD.
> Does it work or not ? My goal is to be able to pass through my USB disks
> and why not,my GPU,nVidia Geforce RTX 2080 ti. I've found this old
> post :*
Put simply: No.
Scott Cheloha writes:
> On Tue, Jul 05, 2022 at 07:15:31AM -0400, Dave Voutila wrote:
>>
>> Scott Cheloha writes:
>>
>> > [...]
>> >
>> > If you fail the test you will see something like this:
>> >
>> >tsc: cpu0/cpu2: sync
Scott Cheloha writes:
> 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.
>
Looking for testers of the following diff that adds reference counting
to vmm(4) to squash race conditions in vm/vcpu teardown and access.
I've put the diff through a lot of stress tests this week (rapidly
creating 30-50 vm's each booting bsd.rd and then rapidly force
terminating them), but
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 configured to enable QEMU features to simplify
its working with vmd(8). This
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 (adding refcnts) easier to swallow.
>
> This chang
Omar Polo writes:
> Dave Voutila wrote:
>> I noticed this today while grepping through a very long kdump output and
>> using something like:
>>
>> $ fgrep -n -m2 -C2 'kevent -1' dump.txt
>> 641- 31513 vmd RET sendmsg 1848/0x738
&g
I noticed this today while grepping through a very long kdump output and
using something like:
$ fgrep -n -m2 -C2 'kevent -1' dump.txt
641- 31513 vmd RET sendmsg 1848/0x738
642- 31513 vmd CALL kevent(5,0x90d4c2e4000,1,0x90d8004a000,2048,0)
643: 31513 vmd RET kevent -1 errno 4
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 (adding refcnts) easier to swallow.
This change removes the calling of vm_teardown from the code path in
ping...would like to get this in if possible so I can move onto fixing
some things in vmm.
Dave Voutila writes:
> tech@,
>
> Continuing my vmm/vmd bug hunt, the following diff adapts
> vcpu_readregs_vmx to optionally load the vmcs on the current cpu. This
> has gone unnotic
1 - 100 of 243 matches
Mail list logo
