On 13.01.2022 17:38, Andrew Cooper wrote:
> In order to fix a VT-x bug, and support MSR_SPEC_CTRL on AMD, there will need
> to be three different access methods for where the guest's value lives.
> However, it would be better not to duplicate the #GP checking logic.
>
> guest_{rd,wr}msr() are always called first in the PV and HVM MSR paths, so we
> can repurpose X86EMUL_UNHANDLEABLE slightly for this. This is going to be a
> common pattern for other MSRs too in the future.
I consider this repurposing risky. Did you consider using e.g.
X86EMUL_DONE or X86EMUL_RETRY instead? Neither of the two is
presently used by the MSR machinery afaics.
What's worse, aren't you making it possible to hit the
ASSERT_UNREACHABLE() in hvm_save_cpu_msrs() as well as in
XEN_DOMCTL_get_vcpu_msrs handling? And have hvm_load_cpu_msrs()
produce -ENXIO and XEN_DOMCTL_set_vcpu_msrs return -EINVAL?
Jan
