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

[Wei Liu]

On Tue, Apr 14, 2026 at 03:49:53PM +0000, Anirudh Rayabharam wrote:
> 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.
> 

I think it is important to keep the changes as small as possible for
ease of backporting.

> 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.
> 

It is possible to configure Vmbus as a module today. We should think of
a way to resolve what you say. Designing a new component is one way. The
other way is to find a working build configuration and enforce it via
Kconfig.

Wei

> Thanks,
> Anirudh.
> 
> > 
> > Best,
> > Jork