TDX: Add support for kernel interrupt offloading

[jaredwhitedev]

The user<-> kernel transitions during IPI handling incur a significant amount of overhead on both the send and receive sides. These changes support handling IPIs entirely in-kernel, eliminating these transitions.

[jaredwhitedev]

Marking as non-draft & ready for review since the only additional change will be a kernel package bump. GitHub copy of the kernel PR: microsoft/OHCL-Linux-Kernel#26

[smalis-msft]

While we're making kernel changes in this area, can we also make whatever changes are needed for the same code to support Guest VSM (i.e. separate tracking of interrupts for VTL 0 and VTL 1)? We're going to need it at some point. We need it for SNP too.

[jaredwhitedev]

While we're making kernel changes in this area, can we also make whatever changes are needed for the same code to support Guest VSM (i.e. separate tracking of interrupts for VTL 0 and VTL 1)? We're going to need it at some point. We need it for SNP too.

The new version only turns on kernel offloading if the next vtl is vtl0. Is that sufficient for now?

[jstarks]

This is going to conflict with #470.

[jstarks]

LGTM but we'll need to update the kernel first.

[smalis-msft]

While we're making kernel changes in this area, can we also make whatever changes are needed for the same code to support Guest VSM (i.e. separate tracking of interrupts for VTL 0 and VTL 1)? We're going to need it at some point. We need it for SNP too.

The new version only turns on kernel offloading if the next vtl is vtl0. Is that sufficient for now?

Honestly I don't think I'm familiar enough with offloading to say for sure. But my understanding is it's solely a perf improvement, and not needed functionality, correct? And if we combine that with believing that VTL 1 will be running a very small percentage of the time compared to VTL 0, and will not be receiving many interrupts, then maybe this perf change isn't necessary for it?

[jaredwhitedev]

While we're making kernel changes in this area, can we also make whatever changes are needed for the same code to support Guest VSM (i.e. separate tracking of interrupts for VTL 0 and VTL 1)? We're going to need it at some point. We need it for SNP too.

The new version only turns on kernel offloading if the next vtl is vtl0. Is that sufficient for now?

Honestly I don't think I'm familiar enough with offloading to say for sure. But my understanding is it's solely a perf improvement, and not needed functionality, correct? And if we combine that with believing that VTL 1 will be running a very small percentage of the time compared to VTL 0, and will not be receiving many interrupts, then maybe this perf change isn't necessary for it?

Definitely yes on "solely a perf improvement, and not needed functionality", and my understanding is yes for the second

[jaredwhitedev]

Rebased, kernel update now included (#568)