On Wed, Oct 09, 2019 at 03:31:49PM +0200, Jan Beulich wrote:
> On 09.10.2019 14:27, Marek Marczykowski-Górecki  wrote:
> > But then, Linux won't have EFI system table pointer either, no? I don't
> > see Xen passing it over in any way.
> 
> Making the system table pointer available e.g. to kexec userspace
> (so it can pass it in whatever suitable way) would be an easy
> addition. Use of SetVirtualAddressMap(), otoh, would have been a
> hard to undo step if I had made Xen's EFI boot path rely on it.
> The kexec situation wrt EFI was very much in flux back then, and
> hence I didn't want to take unnecessary risks of future
> complications. Any step changing the current state of affairs
> wants to provide assurance that it doesn't close roads which we
> may need to go at some point.

I don't agree with the above being a problem - as we can see, expanding
the kexec mechanism to pass EFI system table isn't really necessary to
make it usable for Linux doing crash dump (this is the use case of kexec
here, right?). But even if it would be, we're talking about some new
(possibly Linux-specific) mechanism - in that case, I don't see why it
couldn't also pass over memory map for the runtime services (as set via
SetVirtualAddressMap()) - similar as Linux->Linux kexec does.
On the other hand, lack of SetVirtualAddressMap() do cause real problems
now, making Xen unbootable on some machines. Or noticeably limited (with
efi=no-rs workaround) - while RS aren't that useful for the crash kernel,
they are useful for the main system.

Anyway, it's your call, as the maintainer. The patch series I've sent
implements the approach by your preference.

-- 
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?