[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 Tue, Nov 26, 2019 at 1:20 PM Rich Persaud <persaur@xxxxxxxxx> wrote:
>
> On Nov 26, 2019, at 15:23, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx> wrote:
>
>
> 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.
>
>
> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.