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
