Download raw body.
vmm(4): return error for VMCALL instead of injecting #UD
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. >
vmm(4): return error for VMCALL instead of injecting #UD