All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Roman Shaposhnik <roman@zededa.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)
Date: Tue, 26 Nov 2019 19:32:02 +0100	[thread overview]
Message-ID: <20191126183202.GV5763@mail-itl> (raw)
In-Reply-To: <CAMmSBy_2gQCPOJjo-VWZ3gmbER+5QPNJyQJN3u_SgKDGZQadGg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3303 bytes --]

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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

  reply	other threads:[~2019-11-26 18:32 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-21  6:05 [Xen-devel] Status of 4.13 Jürgen Groß
2019-11-21  7:30 ` Steven Haigh
2019-11-21  7:36   ` Jürgen Groß
2019-11-21  8:41     ` Jan Beulich
2019-11-21 15:20       ` George Dunlap
2019-11-21 15:34         ` Jan Beulich
2019-11-21 16:03           ` George Dunlap
2019-11-21 16:56             ` Jan Beulich
2019-11-21  8:53 ` Jan Beulich
2019-11-21  9:22   ` Roger Pau Monné
2019-11-21 10:57 ` Wei Liu
2019-11-21 14:16   ` Ian Jackson
2019-11-21 17:11     ` Oleksandr Grytsov
2019-11-21 16:20 ` Andrew Cooper
2019-11-21 16:48   ` Jan Beulich
2019-11-21 17:31 ` Roman Shaposhnik
2019-11-21 17:38   ` Andrew Cooper
2019-11-21 19:39     ` Roman Shaposhnik
2019-11-21 22:07       ` Marek Marczykowski-Górecki
2019-11-23  6:00     ` Roman Shaposhnik
2019-11-25  0:47       ` [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) Marek Marczykowski-Górecki
2019-11-26  3:44         ` Roman Shaposhnik
2019-11-26  3:55           ` Marek Marczykowski-Górecki
2019-11-26  7:02             ` Roman Shaposhnik
2019-11-26  8:32               ` [Xen-devel] UEFI support on Dell boxes Jan Beulich
2019-11-26 17:25                 ` Roman Shaposhnik
2019-11-26 17:56               ` [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) Roman Shaposhnik
2019-11-26 18:32                 ` Marek Marczykowski-Górecki [this message]
2019-11-26 20:12                   ` Roman Shaposhnik
2019-11-26 20:18                     ` Andrew Cooper
2019-11-27  9:07                       ` [Xen-devel] UEFI support on Dell boxes Jan Beulich
2019-11-27  9:01                   ` Jan Beulich
2019-11-25 14:02 ` [Xen-devel] Status of 4.13 Doug Goldstein
2019-11-25 14:06   ` Wei Liu
2019-11-25 15:59     ` Roger Pau Monné
2019-11-25 17:07       ` Wei Liu
2019-11-25 17:27         ` Roger Pau Monné
2019-11-25 17:34           ` Andrew Cooper
2019-11-25 17:43             ` Wei Liu
2019-11-25 17:49             ` Roger Pau Monné
2019-11-26  8:30               ` Jan Beulich
2019-11-26  9:08                 ` Roger Pau Monné
2019-11-26  9:32                   ` Jürgen Groß
2019-11-25 14:06   ` Jan Beulich
2019-11-26 21:20 [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13) Rich Persaud
2019-11-26 21:54 ` Roman Shaposhnik
2019-11-27  9:14 ` Jan Beulich
2019-11-27 11:34   ` Marek Marczykowski-Górecki
2019-11-27 11:57 Rich Persaud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191126183202.GV5763@mail-itl \
    --to=marmarek@invisiblethingslab.com \
    --cc=roman@zededa.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.