Re: [PATCH] Call SetVirtualAddressMap() by default

[Jan Beulich <jbeulich@xxxxxxxx>]

On 10.03.2023 17:05, George Dunlap wrote:
> On Fri, Feb 24, 2023 at 8:20 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>> On 23.02.2023 14:56, Marek Marczykowski-Górecki wrote:
>>> Yet, not calling SetVirtualAddressMap() leads to actual issues _right
>>> now_, not in some hypothetical undefined future.
>>
>> That's the way you, Andrew, and others like to put it. My view at this
>> is that it's not the lack of the call, but the improper implementation
>> of firmware which leads to an apparent need for this call. Like for all
>> other firmware bug workarounds, I'm happy to accept any proposals for
>> workarounds, as long as such workarounds either don't impact spec-
>> compliant systems, or as long as they're off by default.
> 
> 
> But it sounds (reading though this thread) like it doesn't impact any
> spec-compliant systems -- that is, not any *known* ones, but only
> hypothetical dom0's which are neither Linux (including kexec) nor NetBSD
> nor FreeBSD.

I can't say anything about the BSDs. Originally, when our EFI support was
first implemented, kexec would have been affected from all I know. The
way it works was changed meanwhile.

As to "known" affected systems: Elsewhere on this thread I pointed out
that I was happy that, at the time, I had an excuse not to worry about
getting our use of SetVirtualAddressMap() correct. Properly establishing
virtual addresses before making that call is still an open issue, for
which I do not yet see a good solution. Marek saying "It works just fine"
can only mean the limited set of systems that were tested. With more of
physical address space populated, said problem would arise. Can I point
at a particular system? No. But I do know that systems with "odd" memory
maps exist (that's what e.g. our PDX abstraction was introduced for),
and I anticipate problems there.

An intermediate approach might be to call SetVirtualAddressMap() on
systems where we can establish a complete virtual address map early
enough. (Saying that without looking at the code, so this may not be
viable in practice.) But I'm unsure this would improve the overall
situation: We'd then test one thing on typical systems and would end up
even less certain whether Xen also works on atypical ones.

> If we were Microsoft, we could afford to say "we don't support this
> hardware", and that would be enough to get the manufacturers to change
> their tune; but we're not.  Making it difficult for our users will not
> fundamentally make vendors write better code.

We can certainly agree on the goal of not making it more difficult than
necessary for users. Provided reasonable command line option documentation,
it shouldn't be overly difficult to establish which workarounds need
enabling for a given platform. For known problematic ones we could even
enable workarounds by default (just like we do in various cases when EFI
does not come into play; most of that was inherited from Linux and hence
is rather dated now, though).

> Particularly as my guess is that it's probably mainly a matter of testing:
> They only do testing on Windows (or maybe Linux if they're particularly
> keen), both of which seem to call SetVirtualAddressMap(); and so bits of
> the code accidentally come to rely on it being called.  Sure, in a perfect
> world, developers would read the spec, automatically follow it, and test on
> all possible hardware; but given how software actually works, it seems
> inevitable that we're going to have a never-ending stream of bugs because
> we're behaving differently.
> 
> So literally the only benefit of your policy is to accommodate hypothetical
> operating systems, who may need the functionality for unknown reasons.  And
> the cost is to have vanilla Xen not work on loads of real systems.  I don't
> think this is the right decision; and it seems like the sort of general
> higher-level principle that it would make sense to have a project-wide vote
> on if discussion failed to reach consensus.

Certainly. I'm pretty sure I would end up in a minority in such an event.
Yet if we started to enable random firmware workarounds by default which
can have an impact on spec-conforming systems, I guess I would have to
seriously consider to step down as the maintainer of our EFI code. But
maybe that's what's wanted by others anyway ...

> (Obviously if there are other technical issues, those would need to be
> addressed first.)
> 
> Supposing such a hypothetical operating system appears, is there any reason
> we can't figure out how to provide it what it needs at that time?

Well - about everything can be done in software. The question is how much
of the necessary road we've ended up closing by going the "account for
quirks by default" route, and hence how complicated things would end up
being.

Jan