From: Nuno Das Neves <redacted> Sent: Friday, March 7, 2025 3:30 PM

On 3/7/2025 9:44 AM, Michael Kelley wrote:

quoted

From: Nuno Das Neves <redacted> Sent: Wednesday, February 26, 2025 3:08 PM

quoted

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