On Mon, Oct 2, 2023 at 6:43 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > - I should go drop the patches annotating kvm_vcpu_read/write_page > > from my series > > Hold up on that. I'd prefer to keep them as there's still value in giving userspace > debug information. All I'm proposing is that we would firmly state in the > documentation that those paths must be treated as informational-only. Userspace would then need to know whether annotations were performed from reliable/unreliable paths though, right? That'd imply another flag bit beyond the current R/W/E bits. > > - The helper function [a] for filling the memory_fault field > > (downgraded back into the current union) can drop the "has the field > > already been filled?" check/WARN. > > That would need to be dropped regardless because it's user-triggered (sadly). Well the current v5 of the series uses a non-userspace visible canary- it seems like there'd still be value in that if we were to keep the annotations in potentially unreliable spots. Although perhaps that test failure you noticed [1] is a good counter-argument, since it shows a known case where a current flow does multiple writes to the memory_fault member. [1] https://lore.kernel.org/all/202309141107.30863e9d-oliver.sang@xxxxxxxxx > Anyways, don't do anything just yet. :salutes: