On Tue, Nov 26, 2019 at 1:20 PM Rich Persaud <pers...@gmail.com> wrote: > > On Nov 26, 2019, at 15:23, Andrew Cooper <andrew.coop...@citrix.com> wrote: > > > On 26/11/2019 20:12, Roman Shaposhnik wrote: > > On Tue, Nov 26, 2019 at 10:32 AM Marek Marczykowski-Górecki > > <marma...@invisiblethingslab.com> wrote: > > On Tue, Nov 26, 2019 at 09:56:25AM -0800, Roman Shaposhnik wrote: > > Hi Marek, after applying Jan's patch I'm making much further progress. > > Xen boots fine and Dom0 seems to be OK (more tests are needed tho on > > my end). > > > I'm attaching the logs from Xen and Dom0. > > > At this point it seems that adding efi=attr=uc is a better option for > > these boxes than a wholesale efi=no-rs > > > Question #1: is this something that EFI_SET_VIRTUAL_ADDRESS_MAP was > > supposed to cover by default (so I don't have to add efi=attr=uc)? > > No, this looks like some different firmware (?) issue. > > > Question #2: is there any downside to *always* specifying efi=attr=uc? > > Even for servers that, strictly speaking, don't need it? > > TL;DR: It should be fine. It is what Linux does too. > > > Details: > > > Lets take a look why 'efi=attr=uc' helps, and how can we make it work > > out of the box: > > > The issue is about memory marked as type=11 (EfiMemoryMappedIO) with > > attr=8000000000000000 (EFI_MEMORY_RUNTIME). Indeed none of cachability > > attribute is defined. For the record, defined attributes are (UEFI spec > > .6): > > > EFI_MEMORY_UC Memory cacheability attribute: The memory region supports > > being configured as not cacheable. > > > EFI_MEMORY_WC Memory cacheability attribute: The memory region supports > > being configured as write combining. > > > EFI_MEMORY_WT Memory cacheability attribute: The memory region supports > > being configured as cacheable with a “write through” policy. > > Writes that hit in the cache will also be written to main memory. > > > EFI_MEMORY_WB Memory cacheability attribute: The memory region supports > > being configured as cacheable with a “write back” policy. Reads > > and writes that hit in the cache do not propagate to main memory. > > Dirty data is written back to main memory when a new cache line > > is allocated. > > > EFI_MEMORY_UCE Memory cacheability attribute: The memory region supports > > being configured as not cacheable, exported, and supports the > > “fetch and add” semaphore mechanism. > > > My reading of UEFI spec doesn't give much hints what to do with memory > > mappings without any cachability attribute. The only related info I've > > found is about EfiMemoryMappedIO: > > > This memory is not used by the OS. All system memory-mapped IO > > information should come from ACPI tables. > > > So, maybe there is some more info? > > > Anyway, if I understand correctly, MMIO region should be mapped as UC, > > right? > > > I've also taken look at what Linux does. And basically, the only bit > > Linux care about is EFI_MEMORY_WB - if it's absent, then set the region > > as uncachable (page cache disabled bit in page table entry). So, > > basically Linux by default does what Xen's efi=attr=uc does. > > Very interesting! Thanks for doing the research. > > > So, to improve Xen's hardware/firmware compatibility, I have two ideas: > > > 1. Make efi=attr=uc the default (it's still possible to disable it with > > efi=attr=no). > > I'd be very much in favor of that too (especially since it seems to match > > Linux behaviour) What do others think? > > > Its more than just this. Linux also doesn't use EFI reboot because it > is broken almost everywhere (because Windows doesn't use it because its > broken almost everywhere, so it never gets fixed). > > Xen should be following Linux, but I'm exhausted arguing this point. > > A consequence is that downstream tend to share a pile of "unbreak Xen on > UEFI" patches which have been rejected upstream on philosophical rather > than technical grounds, despite this being a toxic environment to work in. > > > As an intermediate step, could we have an umbrella opt-in Kconfig option > (CONFIG_EFI_NONSPEC_COMPATIBILITY?) that enables multiple EFI options for > maximum hardware compatibility? For this thread and Xen 4.13, that would be > EFI_SET_VIRTUAL_ADDRESS_MAP and efi=attr=uc. If more options/quirks are > added in the future, downstreams using EFI_NONSPEC_COMPATIBILITY would get > them by default.
As one of those downstream users I have to say I like this A LOT! > The long-term solution is an OSS virtualization-security test tool (e.g. with > Xen and QEMU KVM) that can be run by OEM/ODM QA factory teams on > pre-production firmware and hardware. That is the most OEM-actionable > development window where firmware quality issues can be detected and fixed. > Microsoft's hardware logo/certification work with Windows 10 OEMs on "secured > core" features is also tackling firmware improvements for > virtualization-based security. That's a good proposal, but the question, as always becomes who moves the needle on this one so we avoid a sort of "tragedy of the commons" type of situation. Now, I'm not even talking about writing (and maintaining!) the actual code -- but rather all the BD activities that would have to take place to make it a reality. This actually may be a good question to ask Linux Foundation since I've seen them be helpful in situations like this. > From the business side, Dell/HP/Lenovo + other OEMs and ODMs could add > premium "FirmCare" SKUs into their custom build ordering systems, where > customers could pay a small fee for additional firmware support, custom > root-of-trust (e.g. BootGuard) key management, or even coreboot. This could > move from cost-center incentives [1] to high-margin incentives [2] for > firmware and platform health, safety & security. Another step would be > including firmware requirements in supply chain contracts [3] for large > customer orders. Yup! I could see this as well! > While we wait on these ecosystem improvements, > CONFIG_EFI_NONSPEC_COMPATIBILITY or a similar option for Xen 4.13 would help > users of existing platforms. Right -- because at the end of the day -- as I am discovering now, there seems to be a non-trivial downstream constituency "curating" those types of patches in separate silos (Project EVE included) it would be great to at least have one central bucket (even if non-default and protect by XXX_OPTION) for these patches to be curated -- and that's upstream Xen. Thanks, Roman. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
