Why i'm asking - after macos boot i can see that at least one RT_Data and one ACPI_NVS are remapped into upper memory (0xffffff***) and their phys addr <> virt addr. Also, all MMIO has phys addr <> virt addr (and as i can see clover aptio fix is marking some rt_data as mmio). So i'm wondering if that can't be reason of non working nvram
No, that is to FIX NVRAM access. RT_data gets relocated by boot.efi and thus the SMM-side of the driver doesn't write to the CommBuffer. MMIO pages do not get relocated. Only one RT_data page remains RT_data, and that's the SystemTable, as it needs to be relocated for the kernel not to crash.
A few days ago, you had suspicions on what might be the reasons. Would you mind sharing them ?
My best guess was that the SMM portion of the driver would be calling ConvertPointer() on the CommBuffer - as SMM runs in physical mode though, that would break things if physical != virtual. As far as I know, physical = virtual on Windows and Linux, at least also (one physical address can have multiple virtual ones), which would have explained why it worked there (does it even?). But I didn't find anything the the driver that hints at that yet.
Can be very useful list of places in clover to investigate (at least approximately, i'm good on gathering code )
Nothing in Clover can help you and the code you would be looking for is not open.