On 20.08.2020 21:31, Roman Shaposhnik wrote: > On Thu, Aug 20, 2020 at 1:34 AM Jan Beulich <jbeul...@suse.com> wrote: >> On 20.08.2020 00:50, Roman Shaposhnik wrote: >>> (XEN) Unknown cachability for MFNs 0xff900-0xfffff >> >> The fault address falling in this range suggests you can use a less >> heavy workaround: "efi=attr=uc". (Quite possibly "efi=no-rs" or yet >> some other workaround may still be needed for your subsequent reboot >> hang.) > > I just tried and efi=attr=uc and it is, indeed, a workaround. I can get to > Dom0 booting far enough (and then I hit the other issue). > > However, since efi=attr=uc has always struck me as a bit of a hammer > still I tried the good ol': > https://lists.archive.carbon60.com/xen/devel/408709 > > And then Xen crashed in an interesting way (see below). Now, this > is with CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP -- so not sure > if it is related.
Why "interesting way" - it's the same as before, you're hitting the range reported by "Unknown cachability for MFNs 0xff900-0xfffff" >> As far as making cases like this work by default, I'm afraid it'll >> need to be proposed to replace me as the maintainer of EFI code in >> Xen. I will remain on the position that it is not acceptable to >> apply workarounds for firmware issues by default unless they're >> entirely benign to spec-conforming systems. DMI data based enabling >> of workarounds, for example, is acceptable in the common case, as >> long as the matching pattern isn't unreasonably wide. > > Well, default is overloaded. What I would like to see (and consider it > a void of a small downstream/distro) is a community-agreed and > maintained way of working around these issues. Yes, I'd love to see > it working by default -- but if we can at least agree on an officially > supported knob that is less of a hammer than efi=attr=uc -- that'd > be a good first step. > > Makes sense? Sure, just that I don't see what less heavyweight alternatives to "efi=attr=uc" there are (short of supplying an option to provide per-range memory attributes, which would end up ugly to use). For the specific case here, "efi=attr=wp" could be made work, but might not be correct for all of the range (it's a EfiMemoryMappedIO range, after all); in the majority of cases of lacking attribute information that I've seen, UC was indeed what was needed. Jan
