Re: [PATCH v2 4/6] mshv: limit SynIC management to MSHV-owned resources

From: Anirudh Rayabharam

Date: Tue Apr 14 2026 - 11:50:47 EST


On Tue, Apr 07, 2026 at 02:27:52PM -0700, Jork Loeser wrote:
> On Mon, 6 Apr 2026, Anirudh Rayabharam wrote:
>
> > On Fri, Apr 03, 2026 at 12:06:10PM -0700, Jork Loeser wrote:
> > > The SynIC is shared between VMBus and MSHV. VMBus owns the message
> > > page (SIMP), event flags page (SIEFP), global enable (SCONTROL),
> > > and SINT2. MSHV adds SINT0, SINT5, and the event ring page (SIRBP).
> > >
> > > Currently mshv_synic_init() redundantly enables SIMP, SIEFP, and
> >
> > The redundant enable is probably a no-op from the hypervisor side so it
> > probably doesn't hurt us. The main problem is with the tear down.
>
> It's an MSR intercept. If we can replace this by an "if()" we shave a few
> cycles.
>
> > An alternative approach could be: check if SIMP/SIEFP/SCONTROL is
> > already enabled. If so, don't enable it again. If not enabled, enable it
> > and keep track of what all stuf we have enabled. Then disable all of
> > them during cleanup. This approach makes less assumptions about the
> > behavior of the VMBUS driver and what stuff it does or doesn't use.
>
> It would, yes. Then again, we drag yet more state and make debugging more
> complicated / less clear to reason what happens dynamically. I had been
> debating this briefly myself, and ultimately decided against it for that
> very reason.

Ultimately, both approaches are fragile in their own ways because the
contract that "VMBus owns SIMP, SIEFP, SCONTROL, SINT2 and MSHV owns
SIRBP and SINT0 and SINT5" are not enforced anywhere in code and are
just assumptions that everyone will play nice. To do that, we'll need to
refactor the code such that there is a common component that sort of
facilitates access to SynIC for both VMBus and MSHV.

I would say that checking the state dynamically and then deciding
whether or not to enable SIMP/SIEFP/SCONTROL would be less fragile
because we make lesser assumptions about what VMBus does or doesn't do.

Also, do you know of any cases where the VMBus stuff can get initialized
after MSHV? Maybe if VMBus is a module (if that is even possible)? That
would really mess up our logic here.

Thanks,
Anirudh.

>
> Best,
> Jork