On 9/7/23 11:59 PM, Borislav Petkov wrote:
> On Thu, Sep 07, 2023 at 08:08:00PM -0700, Elliott Mitchell wrote:
>> This reverts commit 767f4b620edadac579c9b8b6660761d4285fa6f9.
>>
>> There are at least 3 valid reasons why a VM may see MCE events/registers.
>
> Hmm, so they all read like a bunch of handwaving to me, with those
> probable hypothetical "may" formulations.
>
> How about we cut to the chase and you explain what exactly is the
> concrete issue you're encountering and trying to solve?
Also, please note that the EDAC modules don't handle MCE events
directly. They act on information passed from the MCE subsystem.
Furthermore, there are other EDAC modules that have the same !hypervisor
check, so why change only this one?
Thanks,
Yazen
> Also, please note that the EDAC modules don't handle MCE events
> directly. They act on information passed from the MCE subsystem.
>
> Furthermore, there are other EDAC modules that have the same !hypervisor
> check, so why change only this one?
The older Intel EDAC drivers translated system physical addresses to DIMM
addresses by digging around in the CONFIG and MMIO space of the memory
controller devices. It would seem unwise for a VMM to give access to those
addresses to a guest (in general ... perhaps OK for a Xen style "DOM0" guest that is
handling many tasks for the VMM?).
What system resources do AMD EDAC drivers need access to? Could they
work inside a guest?
-Tony