Re: [PATCH][4.15] x86/shadow: suppress "fast fault path" optimization without reserved bits

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.03.2021 13:32, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH][4.15] x86/shadow: suppress "fast fault path" 
> optimization without reserved bits"):
>> On 01.03.2021 18:43, Ian Jackson wrote:
>>> Andrew Cooper writes ("Re: [PATCH][4.15] x86/shadow: suppress "fast fault 
>>> path" optimization without reserved bits"):
>>>> On 01/03/2021 17:30, Ian Jackson wrote:
>>>>> I'm afraid I don't follow enough of the background here to have an
>>>>> opinion right now.  Can someone explain to me the risks (and,
>>>>> correspondingly, upsides) of the options ?  Sorry to be dim, I don't
>>>>> seem to be firing on all cylinders today.
>>
>> I guess the risk from that patch is no different than that from the
>> patch here. It would merely improve performance for guests using
>> very large GFNs for memory areas needing emulation by qemu, which I
>> suppose originally wasn't expected to be happening in the first place.
>> In fact if I would have been certain there are no side effects of the
>> too narrow GFN representation used so far, I would probably have
>> submitted the patches in reverse order, or even folded them.
> 
> I am still confused.  You are saying that the existing patch, and your
> proposal that you are wanting me to have an opinion on, have the same
> risk.  So, what aspect of the proposed other way of fixing it might
> make me say no ?

Yet another change / yet more code churn for merely improving what
got fixed already. But, oh, there looks to be a misunderstanding
nevertheless - I'm not proposing another way of addressing the
same issue, but instead a performance improvement (for perhaps
just an unlikely case) on top of the fix that you did give your
ack for already. (As said - had I been certain of no aspect that
I might be overlooking, I might have folded that. But I wasn't
certain, and hence I did post the basic fix first / individually.)

Jan