Re: [Xen-devel] [PATCH for 4.13] x86/shim: don't reserve 640k - 1M region in E820

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.10.2019 12:15, Andrew Cooper wrote:
> On 28/10/2019 11:11, Jan Beulich wrote:
>> On 28.10.2019 12:08, Sergey Dyasli wrote:
>>> On 28/10/2019 09:06, Jan Beulich wrote:
>>>> On 28.10.2019 09:56, Sergey Dyasli wrote:
>>>>> Converting a guest from PV to PV-in-PVH makes the guest to have 384k
>>>>> less memory, which may confuse guest's balloon driver. This happens
>>>>> because Xen unconditionally reserves 640k - 1M region in E820 despite
>>>>> the fact that it's really a usable RAM in PVH boot mode.
>>>> This is a PVH property according to your description and according
>>>> to my understanding. Why would you then ...
>>>>
>>>>> Fix this by skipping the region type change for pv-shim mode.
>>>> ... alter behavior for shim mode only, rather than when booted in
>>>> PVH mode in general?
>>> This is just me being cautious.
>>>
>>> My original email does have this text after ---
>>> "The condition can be relaxed to be just !pvh_boot if there are no
>>> plans to support VGA MMIO / ROMs for PVH guests."
>> I doubt emulated ones are intended to be supported, but of
>> course a graphics card could be passed through. Iirc passthrough
>> is a pending work item still anyway for PVH, so dealing with the
>> case right now may not even be necessary.
> 
> The bug is Xen blindly presuming that a missing hole "must be a firmware
> bug".
> 
> I can believe that there may have been systems decades ago which got
> this wrong, but tbh I doubt it applies to 64bit-capable systems,
> considering how standardised things were by then.
> 
> I'd just delete this whole piece of logic and call it done.

Well, I could see use being less aggressive here, but firmware (if
there is firmware, i.e. everything except PVH) claiming there to
be RAM immediately below the 1M boundary is a pretty good sign of
something being wrong. There _ought_ to be ROM at that address.
Otoh there were even ways in older chipsets to make RAM appear at
address ranges not used by option ROMs, so the logic we currently
have goes too far potentially even on bare metal.

So while I'm all for relaxing, I don't think I can support
outright deletion.

Jan

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