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

[Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>]

On 28/10/2019 11:33, Andrew Cooper wrote:
> On 28/10/2019 11:30, Jan Beulich wrote:
>> 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.
> 
> For now, how about cpu_has_hypervisor ?
> 
> Whatever the virtual environment, we should trust the provided memory map.

Unfortunately, this plan has failed: init_e820() is called way before
early_cpu_init() and testing cpu_has_hypervisor is meaningless there.

I guess I'll go for !pvh_boot check for now.

--
Thanks,
Sergey

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