|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)
On 26/11/2019 20:12, Roman Shaposhnik wrote: > On Tue, Nov 26, 2019 at 10:32 AM Marek Marczykowski-Górecki > <marmarek@xxxxxxxxxxxxxxxxxxxxxx> 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. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |