Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)

[Roman Shaposhnik <roman@xxxxxxxxxx>]

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?

> 2. Map type=11 (MMIO) as UC, unless attributes specify otherwise.

This seems to be the subset of the #1 option. As such -- perhaps it
is "safer" than a wholesale efi=attr=uc but at the same time Linux
behaviour gives me pretty good confidence that we should probably
be safe, no?

> Any preference? I can prepare a patch for either version. But I guess
> it's too late for getting it into 4.13.

Good question as well.

Thanks,
Roman.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel