Hi,

On Thu, Jun 26, 2025 at 01:58:32PM -0700, Mike Larkin wrote:
> >
> >  	switch (sw_exitcode) {
> > +	case SVM_VMEXIT_CPUID:
> > +		ghcb_sync_val(GHCB_RAX, GHCB_SZ32, &syncout);
> > +		ghcb_sync_val(GHCB_RCX, GHCB_SZ32, &syncout);
> > +		ghcb_sync_val(GHCB_RAX, GHCB_SZ32, &syncin);
> > +		ghcb_sync_val(GHCB_RBX, GHCB_SZ32, &syncin);
> > +		ghcb_sync_val(GHCB_RCX, GHCB_SZ32, &syncin);
> > +		ghcb_sync_val(GHCB_RDX, GHCB_SZ32, &syncin);
> > +		frame->tf_rip += 2;
> > +		break;
> > +	case SVM_VMEXIT_MSR: {
> > +		if (*rip == 0x0f && *(rip + 1) == 0x30) {
> 
> Maybe it's just me but it took me a few minutes to wrap my head around this
> when I read it for the first time in that earlier version of the diff.
> 
> For posterity, can we add something like this (somewhere, maybe above the
> switch?) :
> 
> 	/*
> 	 * The #VC trap occurs when the guest (us) performs an operation which
> 	 * requires sharing data with the host. In order to ascertain
> 	 * which instruction caused the #VC, examine the instruction by
> 	 * reading %rip, Then, sync the appropriate values out (to the host),
> 	 * perform VMGEXIT to request that the host handle the operation which
> 	 * caused the #VC, then sync the returned values back in (from
> 	 * the host).
> 	 */

yes!  I will add that comment to make clear what's going on here.

• smime.p7s (5K)