Index | Thread | Search

From:
Nick Owens <mischief@offblast.org>
Subject:
Re: vmm(4): return error for VMCALL instead of injecting #UD
To:
tech@openbsd.org
Date:
Tue, 17 Mar 2026 09:17:21 -0700

Download raw body.

Thread
On Tue, Mar 17, 2026 at 6:52 AM hshoexer <hshoexer@yerbouti.franken.de> wrote:
>
> Hi,
>
> On Mon, Mar 16, 2026 at 04:51:21PM -0400, Dave Voutila wrote:
> > ...
> > I think VMX will give us a valid instruction length we can
> > retrieve and trust.
> >
> > For SVM, I think nRIP is applicable here and should be accurate? I think
> > we're at a point where we might want to enforce nRIP support if we don't
> > already. (I think this has come up before.)
>
> like the diff below?  If we want to go that direction, VMCALL and
> VMMCALL handling could be refactored in a single function.  And
> there are some more places in the SVM specific code where we could
> use nRIP, too.
>
> @ Miguel:  Using the metal-amd64.iso (talos linux?) I can reproduce
> that issue on both AMD/SVM and Intel/VMX vmm.  And skipping the vm
> call as you suggest resolves that issue (ie. ptp_kvm fails gracefully).
>
> However, on AMD I see later on MMIO related exits that vmd can not
> handle yet.  And the vm is terminated.  I have not investigated
> this yet, but I guess for AMD/SVM vmm there is more to be done to
> get that talos linux running.

i worked around this locally by enabling the MMIO_NOTYET code in
x86_vm.c, which let me run newer linux kernels.

>
> Do you test on Intel or AMD machines?
>
> Take care,
> HJ.
>