On 18/09/2023 23:00, William Roche wrote: > Hi John, > > I'd like to put the emphasis on the fact that ignoring the SRAO error > for a VM is a real problem at least for a specific (rare) case I'm > currently working on: The VM migration. > > Context: > > - In the case of a poisoned page in the VM address space, the migration > can't read it and will skip this page, considering it as a zero-filled > page. The VM kernel (that handled the vMCE) would have marked it's > associated page as poisoned, and if the VM touches the page, the VM > kernel generates the associated MCE because it already knows about the > poisoned page. > > - When we ignore the vMCE in the case of a SIGBUS/BUS_MCEERR_AO error > (what this patch does), we entirely rely on the Hypervisor to send an > SRAR error to qemu when the page is touched: The AMD VM kernel will > receive the SIGBUS/BUS_MCEERR_AR and deal with it, thanks to your > changes here. > > So it looks like the mechanism works fine... unless the VM has migrated > between the SRAO error and the first time it really touches the poisoned > page to get an SRAR error ! In this case, its new address space > (created on the migration destination) will have a zero-page where we > had a poisoned page, and the AMD VM Kernel (that never dealt with the > SRAO) doesn't know about the poisoned page and will access the page > finding only zeros... We have a memory corruption ! > > It is a very rare window, but in order to fix it the most reasonable > course of action would be to make the AMD emulation deal with SRAO > errors, instead of ignoring them. > > Do you agree with my analysis ?
Under the case that SRAO aren't handled well in the kernel today[*] for AMD, we could always add a migration blocker when we hit AO sigbus, in case ignoring is our only option. But this would be less than ideal to propagating the SRAO into the guest. [*] Meaning knowing that handling the SRAO would generate a crash in the guest Perhaps as an improvement, perhaps allow qemu to choose to propagate should this limitation be lifted via a new -action value and allow it to ignore/propagate or not e.g. -action mce=none # default on Intel to propagate all MCE events to the guest -action mce=ignore-optional # Ignore SRAO I suppose the second is also useful for ARM64 considering they currently ignore SRAO events too. > Would an AMD platform generate SRAO signal to a process > (SIGBUS/BUS_MCEERR_AO) in case of a real hardware error ? > This would be useful to confirm. > Thanks, > William.
