From: Nuno Das Neves <nunodasneves@xxxxxxxxxxxxxxxxxxx> Sent: Friday, March 7, 2025 3:30 PM > > On 3/7/2025 9:44 AM, Michael Kelley wrote: > > From: Nuno Das Neves <nunodasneves@xxxxxxxxxxxxxxxxxxx> Sent: Wednesday, February 26, 2025 3:08 PM > > > >> > >> This will handle SYNIC interrupts such as intercepts, doorbells, and > >> scheduling messages intended for the mshv driver. > > > > Could you provide a bit more detailed commit message? How does > > the mshv_handler() relate to the vmbus_handler()? From the code > > mshv_handler() goes first, and I'm assuming it processes what it > > knows about (intercepts, doorbells, scheduling messages?) and > > then hands off control to the vmbus_handler() to handle the usual > > VMbus-related message and channel interrupts. But it would be > > nice to have the commit message or code comments describe the > > overall intent and any obscure aspects of the relationship. > > > > And avoid references to "This" or "This patch". :-) > > > > You've described it pretty well, I don't know if there's too much > more to say given this patch doesn't introduce the handler code. > > I can try to improve it, something like: > " > mshv_handler() will be used to process messages related to managing > guest partitions such as intercepts, doorbells, and scheduling messages. > > In a (non-nested) root partition, the same interrupt vector is shared > between the vmbus and mshv_root drivers. > > Introduce a stub for mshv_handler() and call it in > sysvec_hyperv_callback alongside vmbus_handler(). > > Even though both handlers will be called for every Hyper-V interrupt, > the messages for each driver are delivered to different offsets within > the SYNIC message page, so they won't step on each other. > " > > Does that work? Yes, that works. I was going to ask how the two handlers could Both be used on the same interrupt, and you've provided the explanation, which is perfect. ;-) Minor tweak: Start the first sentence as an imperative: Add mshv_handler() to process messages related ..... Michael
