[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 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.

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).

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

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

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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®.