Re: [PATCH v9 00/22] Enable FRED with KVM VMX

[Maciej Wieczor-Retman]

On 2026-05-05 at 21:27:12 +0100, Andrew Cooper wrote:
>On 05/05/2026 9:20 pm, Maciej Wieczor-Retman wrote:
>> On 2026-05-05 at 19:30:21 +0100, Andrew Cooper wrote:
>>> On 05/05/2026 7:04 pm, Maciej Wieczor-Retman wrote:
>>>
>>>> I think you'd need to add another check in vmx_inject_exception() to handle that
>>>> DB_VECTOR too. Simply changing the event type if the vector is of DB_VECTOR type
>>>> fixes that problem but then the selftest fails in other places (assert
>>>> fred_handler_called and saved rip vs expected_rip). I didn't yet have the time
>>>> to figure out what could be wrong there, maybe you would have more of an idea :)
>>> #DB is intercepted to mitigate CVE-2015-8104 (systemwide DoS).  But, to
>>> start with, check that the test passes when #DB is not intercepted. 
>>> That's the basecase for architectural behaviour.
>> I take it you mean dropping the ICEBP selftest test case and just checking INT3
>> and INT $0x20? In that case the other two tests pass after a minor change -
>> namely in guest_code() the expected_rip needs to be volatile as well. Otherwise
>> there is a RIP mismatch.
>>
>> Or did you mean I should check something else?
>
>The selftest is correct AIUI.  You should be able to prove this by
>disabling #DB interception, and observing the test to pass.

Okay, I commented out '(1u << DB_VECTOR)' from vmx_update_exception_bitmap(),
and booting with that and applying the two changes to the selftest that I
mentioned [1] it passes as you said.

>Then, there's a logic bug to fix to cause the test to pass even when #DB
>interception is active (which is necessary due to CVE-2015-8104).

I'll dig around the #DB thing, maybe I'll figure out what's wrong there.

>
>~Andrew

[1] Changes being making fred_handler() non-static and making expected_rip
volatile.

-- 
Kind regards
Maciej Wieczór-Retman