From: Jan Beulich <jbeulich@suse.com>
To: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Cc: Juergen Gross <jgross@suse.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen 4.12 panic on Thinkpad W540 with UEFI mutiboot2, efi=no-rs workarounds it
Date: Wed, 9 Oct 2019 10:56:56 +0200 [thread overview]
Message-ID: <815f3cbc-22c3-5a02-429b-0cdf12d84917@suse.com> (raw)
In-Reply-To: <20191008162922.GL8065@mail-itl>
On 08.10.2019 18:29, Marek Marczykowski-Górecki wrote:
> On Tue, Oct 08, 2019 at 04:19:13PM +0200, Jan Beulich wrote:
>> On 08.10.2019 15:52, Marek Marczykowski-Górecki wrote:
>>> Regardless of SetVirtualAddressMap() discussion, I propose to
>>> automatically map boot services code/data, to make Xen work on more
>>> machines (even if _we_ consider those buggy).
>>
>> I remain on my prior position: Adding command line triggerable
>> workarounds for such cases is fine. Defaulting to assume buggy
>> firmware is acceptable only if this means no extra penalty to
>> systems with conforming firmware. Hence, for the case at hand,
>> I object to doing this automatically; we already have the
>> /mapbs workaround in place to deal with the case when xen.efi
>> is used. Judging from the title here there may need to be an
>> addition to also allow triggering this from the MB2 boot path.
>
> What about mirroring Linux behavior? I.e. mapping those regions for the
> SetVirtualAddressMap() time (when enabled) and unmapping after - unless
> tagged with EFI_MEMORY_RUNTIME?
> Similarly to Andrew, I'd really prefer for Xen to work out of the box,
> with as little as possible manual tweaks needed.
If there's going to be a config where SetVirtualAddressMap() is to
be called - why not? But the same logic doesn't make sense when
such a call won#t happen in the first place.
>>>>> Then I've tried a different approach: call SetVirtualAddressMap(), but
>>>>> with an address map that tries to pretend physical addressing (the code
>>>>> under #ifndef USE_SET_VIRTUAL_ADDRESS_MAP). This mostly worked, I needed
>>>>> only few changes:
>>>>> - set VirtualStart back to PhysicalStart in that memory map (it was set
>>>>> to directmap)
>>>>> - map boot services (at least for the SetVirtualAddressMap() call time,
>>>>> but haven't tried unmapping it later)
>>>>> - call SetVirtualAddressMap() with that "1:1" map in place, using
>>>>> efi_rs_enter/efi_rs_leave.
>>>>>
>>>>> This fixed the issue for me, now runtime services do work even without
>>>>> disabling ExitBootServices() call. And without any extra
>>>>> platform-specific command line arguments. And I think it also shouldn't break
>>>>> kexec, since it uses 1:1-like map, but I haven't tried. One should
>>>>> simply ignore EFI_UNSUPPORTED return code (I don't know how to avoid the
>>>>> call at all after kexec).
>>>>
>>>> That's the point - it can't be avoided, and hence it failing is not
>>>> an option. Or else there needs to be a protocol telling kexec what
>>>> it is to expect, and that it in particular can't change the virtual
>>>> address map to its liking. Back at the time when I put together the
>>>> EFI booting code, no such protocol existed, and hence calling
>>>> SetVirtualAddressMap() was not an option. I have no idea whether
>>>> things have changed in the meantime.
>>>
>>> Hmm, how is it different from the current situation? Not calling
>>> SetVirtualAddressMap() means UEFI will not be notified about new address
>>> map. It does _not_ mean it will use 1:1 map, it will use what was
>>> previously set.
>>
>> What do you mean by "previously set"? SetVirtualAddressMap() can be
>> invoked only once during a given session (i.e. without intervening
>> boot). How would other than a 1:1 map have got set?
>
> Like, in the very next sentence of my answer:
>
>>> What if Xen was kexec'ed from Linux?
Honestly - I'm getting tired. You said yourself ...
>>> In Linux case, it looks like it passes around the EFI memory map using
>>> some Linux-specific mechanism, but I don't find it particularly
>>> appealing option.
... that this would require Xen following a Linux protocol.
This is nothing that can work building on EFI interfaces alone.
>>> What about something in between: make this SetVirtualAddressMap() call
>>> compile-time option (kconfig), depending on !CONFIG_KEXEC ? And when
>>> enabled, properly handle SetVirtualAddressMap() failure.
>>
>> What is "proper handling" here?
>
> Logging the error and either panic or disabling runtime services (I tend
> to the latter).
Hmm, yes, disabling runtime services in this case makes sense.
But are you sure a SetVirtualAddressMap() failure doesn't incur
other potential issues later on? (Calling panic() is what I'd
rather not call "proper handling", but rather "emergency
handling".)
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-10-09 8:57 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190807132657.GA2852@mail-itl>
2019-08-07 13:50 ` [Xen-devel] Xen 4.12 panic on Thinkpad W540 with UEFI mutiboot2, efi=no-rs workarounds it Andrew Cooper
2019-08-07 14:45 ` Jan Beulich
[not found] ` <20190807151703.GA2659@mail-itl>
2019-08-07 15:33 ` Jan Beulich
2019-08-07 15:51 ` Marek Marczykowski-Górecki
2019-08-07 15:58 ` Jan Beulich
2019-08-07 16:04 ` Marek Marczykowski-Górecki
2019-08-07 16:34 ` Jan Beulich
[not found] ` <20190807192557.GC3257@mail-itl>
2019-08-08 2:53 ` Marek Marczykowski-Górecki
2019-08-08 6:03 ` Jan Beulich
2019-10-08 11:50 ` Marek Marczykowski-Górecki
2019-10-08 13:08 ` Jan Beulich
2019-10-08 13:52 ` Marek Marczykowski-Górecki
2019-10-08 14:19 ` Jan Beulich
2019-10-08 16:29 ` Marek Marczykowski-Górecki
2019-10-09 0:40 ` Marek Marczykowski-Górecki
2019-10-09 8:56 ` Jan Beulich [this message]
2019-10-09 10:31 ` Marek Marczykowski-Górecki
2019-10-09 10:50 ` Jan Beulich
2019-10-09 11:00 ` Marek Marczykowski-Górecki
2019-10-09 11:48 ` Jan Beulich
2019-10-09 11:52 ` Marek Marczykowski-Górecki
2019-10-09 12:07 ` Jan Beulich
2019-10-09 12:21 ` Marek Marczykowski-Górecki
2019-10-09 12:24 ` Jan Beulich
2019-10-09 12:27 ` Marek Marczykowski-Górecki
2019-10-09 13:31 ` Jan Beulich
2019-10-09 23:57 ` Marek Marczykowski-Górecki
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=815f3cbc-22c3-5a02-429b-0cdf12d84917@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=jgross@suse.com \
--cc=marmarek@invisiblethingslab.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).