On 26/05/2025 10:10 pm, Manuel Bouyer wrote: > On Mon, May 26, 2025 at 10:56:41PM +0200, Manuel Bouyer wrote: >> On Mon, May 26, 2025 at 09:30:53PM +0100, Andrew Cooper wrote: >>> On 26/05/2025 9:13 pm, Manuel Bouyer wrote: >>>> On Mon, May 26, 2025 at 07:50:14PM +0100, Andrew Cooper wrote: >>>>> [...] >>>>> Well, that range does include the aforementioned commit. >>>>> >>>>> Can you bisect around d32c77f471fb8400b6512c171a14cdd58f04f0a3 which is >>>>> the backport of ^ in 4.18 ? >>>> Sure, >>>> with 0d5f15e and d32c77f the test pass, with cecee35 it fails. >>>> >>> Oh interesting, so the basic forwarding of #DB back into a guest >>> (d32c77f) works fine, but the changes to emulated debug exceptions >>> (cecee35) break. >>> >>> Anyway, I think I've spotted a logical error. We do indeed end up >>> calling x86_merge_dr6() twice, because of the TODO just out of context. >>> Does this help? >> Yes, it works for cecee35; now testing with 4.18.5 > yes, it works with 4.18.5 too. All dbreg-related tests now pass again > thanks ! >
Sorry I screwed it up so badly, and apparently also my own testing... May I take that as a Tested-by tag on the patch then? I'll get the fix merged once it's been reviewed, but 4.18 is in security-only support right now and is unlikely to get this as a backport. Are you able to take the patch logically for NetBSD? ~Andrew
