Re: kern/60887: nvmm(4): x86 VMX CR0 guest/host mask does not trap CR0.PE; guest mode switches leave VMCS state stale

["David via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60887; it has been noted by GNATS.

From: "David" <david@crap.solutions>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/60887: nvmm(4): x86 VMX CR0 guest/host mask does not trap
 CR0.PE; guest mode switches leave VMCS state stale
Date: Sat, 17 Oct 2026 18:28:26 +0000

 --dedbddc0-7d06-493c-9b72-d23d73b73479-1
 Content-Type: text/plain; charset="utf-8"
 Content-Transfer-Encoding: quoted-printable
 
 Please close this PR, the analysis was wrong, sorry for the noise.
 
 The CPU performs the real-to-protected-mode switch itself, and trapping C=
 R0.PE only changed the exit timing.
 The failure I saw came from INIT/SIPI delivery in QEMU's nvmm accelerator=
  on DragonFly,
 whose libnvmm still has the v1 API without nvmm_vcpu_stop(), so QEMU cann=
 ot kick a running vCPU.
 NetBSD-current has nvmm_vcpu_stop(), and I have no evidence that NetBSD i=
 s affected.
 
 Thanks and sorry again,
 David
 
 
 
 October 16, 2026 at 6:55 AM, gnats-admin%netbsd.org@localhost mailto:gnats-admin@ne=
 tbsd.org  wrote:
 
 
 >=20
 >=20Thank you very much for your problem report.
 > It has the internal identification `kern/60887'.
 > The individual assigned to look at your
 > report is: kern-bug-people.=20
 >=20
 > >=20
 >=20> Category: kern
 > > Responsible: kern-bug-people
 > > Synopsis: nvmm(4): x86 VMX CR0 guest/host mask does not trap CR0.PE; =
 guest mode switches leave VMCS state stale
 > > Arrival-Date: Fri Oct 16 04:55:00 +0000 2026
 > >
 >
 --dedbddc0-7d06-493c-9b72-d23d73b73479-1
 Content-Type: text/html; charset="utf-8"
 Content-Transfer-Encoding: quoted-printable
 
 <!DOCTYPE html><html><head><meta http-equiv=3D"Content-Type" content=3D"t=
 ext/html; charset=3Dutf-8"></head><body><div>Please close this PR, the an=
 alysis was wrong, sorry for the noise.</div><div><br></div><div>The CPU p=
 erforms the real-to-protected-mode switch itself, and trapping CR0.PE onl=
 y changed the exit timing.</div><div>The failure I saw came from INIT/SIP=
 I delivery in QEMU's nvmm accelerator on DragonFly,</div><div>whose libnv=
 mm still has the v1 API without nvmm_vcpu_stop(), so QEMU cannot kick a r=
 unning vCPU.</div><div>NetBSD-current has nvmm_vcpu_stop(), and I have no=
  evidence that NetBSD is affected.</div><div><br></div><div>Thanks and so=
 rry again,</div><div>David</div><div><br></div><p>October 16, 2026 at 6:5=
 5 AM, <a href=3D"mailto:gnats-admin%netbsd.org@localhost"; target=3D"_blank" tabinde=
 x=3D"-1">gnats-admin%netbsd.org@localhost</a> wrote:</p><blockquote>Thank you very =
 much for your problem report.<br>It has the internal identification `kern=
 /60887'.<br>The individual assigned to look at your<br>report is: kern-bu=
 g-people. <br><br><blockquote>Category:       kern<br>Responsible:    ker=
 n-bug-people<br>Synopsis:       nvmm(4): x86 VMX CR0 guest/host mask does=
  not trap CR0.PE; guest mode switches leave VMCS state stale<br>Arrival-D=
 ate:   Fri Oct 16 04:55:00 +0000 2026</blockquote></blockquote><div><br><=
 /div></body></html>
 --dedbddc0-7d06-493c-9b72-d23d73b73479-1--