On 9/11/2026 2:36 PM, Sohil Mehta wrote:
Patch structure
---------------
Since now at the 10th iteration, and I saw Sean gave a bunch of feedback
already, I suppose pieces are quite sorted out. So I'm more interested
in how those pieces could be organized to make easier to follow, review,
and integrate going forward.
Patches 1-6: Enable the VMX controls and export the host stacks
These seem to be preparatory changes for supporting the state and
extending event delivery later in this series.
Would it make sense to put the x86 core preparation up front rather than
having it in the middle of the KVM changes?
Patches 7-19: Virtualize the FRED context and advertise it to userspace
I think there are a few sub-groups here:
(1) patch07-10: Support FRED state context switching
(2) patch11-14: Extend event delivery
(3) patch15-17: Handle CR4
(4) patch18-19: Advertise the feature, etc.
At glance, (2) looks a little difficult to follow. Patch 13/14 in
particular appear to mix the FRED support itself with some preparatory
changes. IIUC, the code is saying everything outside of the
is_fred_enabled() path has no functional change.
Perhaps, the changes outside of is_fred_enabled() could be separated
out. That would make the actual is_fred_enabled() path easier to follow.
Also, the part introduces the ABI immediately after adding
is_fred_enabled(), before showing up the callsite of is_fred_enabled().
This flow is a bit abrupt.
For example, extending kvm_requeue_exception() alone could be one step.
The next step could add the code under is_fred_enabled(), initially with
is_fred_enabled() as a placeholder that simply returns false. I think
that would better highlight which parts are actually FRED-specific and
why this dynamic check is needed.
Since is_fred_enabled() depends on CR4 anyway, its actual implementation
could then come with (3), or somewhere later. Finally, (2) could perhaps
be completed by adding the new ABI at the end.
Patches 20-25: Extend FRED virtualization to nested VMX
Since nVMX support comes after exposing the feature, does that also mean
the series could be partitioned into two parts, one up through the
advertisement (and tests) and another for nVMX support? Splitting up a
complex series like this may make review and integration easier going
forward.
Thanks,
Chang
