On 21/08/2025 16:25, Borislav Petkov wrote: > On Thu, Aug 21, 2025 at 10:24:22AM +0300, Adrian Hunter wrote: >> Something like below would work, but doesn't answer Dave's question >> of why not do it in mce_read_aux() Thanks for looking at this. > So, let me see what I understand from all this bla: you want to zap the KeyID > from mci_addr because it is completely useless there. So zap it. Not exactly. I just want to fix the bug whereby the mce handler fails to mark the affected page as poisoned because it does not remove the KeyID from the address before looking-up the page. > You can't make any other changes to mci_addr because that goes to luserspace. > > So far so good. > > Now, all that other bla leads me to believe that there might be some need to > dump the raw mci_addr value after all. > > If so, your patch is not needed. > > Which makes me think, all yall folks need to make up your mind here. > > And you need to get rid of all that extraneous information in your commit > message: > > "Investigation of user space expectations has concluded it..." > > No investigation needed - this is exported to userspace so you can't touch it. It is a bit of a grey area. No one expects to find non-address bits in struct mce addr, and the kernel already strips low-order bits, and in the case of SMCA, high-order bits too, refer smca_extract_err_addr(). > The one and only question you need to answer is, do you really need KeyID in > it or not. And whatever you do, once you do it, we're stuck with it because it > goes out to userspace. No, the KeyID is almost useless. It is just a dynamically allocated number. It might indicate which TDX VM encountered the error, except the MCE is fatal to the VM, so a fatal error is reported to the VMM anyway. However, it is allowed to extend struct mce, so adding KeyID or raw MCI ADDR later is quite possible. > Especially if you want this backported to stable. The bug exists in stable. Ideally it would get fixed there too somehow.
