On Thu, Apr 01, 2021 at 01:44:59PM +0100, Andrew Cooper wrote:
> On 01/04/2021 11:22, Roger Pau Monne wrote:
> > The HV_X64_MSR_EOI wrmsr should always happen with the target vCPU
> > as current, as there's no support for EOI'ing interrupts on a remote
> > vCPU.
> >
> > While there also turn the unconditional assert at the top of the
> > function into an error on non-debug builds.
> >
> > No functional change intended.
> >
> > Requested-by: Jan Beulich <jbeul...@suse.com>
> > Signed-off-by: Roger Pau Monné <roger....@citrix.com>
> > ---
> > xen/arch/x86/hvm/viridian/synic.c | 11 ++++++++++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/x86/hvm/viridian/synic.c
> > b/xen/arch/x86/hvm/viridian/synic.c
> > index 22e2df27e5d..e18538c60a6 100644
> > --- a/xen/arch/x86/hvm/viridian/synic.c
> > +++ b/xen/arch/x86/hvm/viridian/synic.c
> > @@ -79,11 +79,20 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx,
> > uint64_t val)
> > struct viridian_vcpu *vv = v->arch.hvm.viridian;
> > struct domain *d = v->domain;
> >
> > - ASSERT(v == current || !v->is_running);
> > + if ( v != current && v->is_running )
> > + {
> > + ASSERT_UNREACHABLE();
> > + return X86EMUL_EXCEPTION;
> > + }
>
> The original ASSERT() was correct - both of these are easily reachable
> in control domain context.
I'm confused, if it's reachable from control domain context then it
shouldn't be an assert?
> If you want EOI to not be used, you need to raise #GP from it, but that
> in principle breaks introspection which really does write MSRs on the
> guests behalf.
Looking at hvm_msr_write_intercept I see that indeed introspection can
monitor an MSR and defer a write, but AFAICT the postponed write will
be performed in guest vcpu context as part of
hvm_vm_event_do_resume?
Also AFAICT there's no way for a control domain to write to this MSR
ATM, as the allowed list in hvm_load_cpu_msrs doesn't contain
HV_X64_MSR_EOI.
Thanks, Roger.
