On 26.08.2022 20:15, Demi Marie Obenour wrote:
> On Fri, Aug 26, 2022 at 09:18:50AM +0200, Jan Beulich wrote:
>> On 25.08.2022 22:36, Demi Marie Obenour wrote:
>>> On Thu, Aug 25, 2022 at 09:59:56AM +0200, Jan Beulich wrote:
On 24.08.2022 23:04, Demi Marie Obenour wrote:
> Fix both of thes
On Fri, Aug 26, 2022 at 09:18:50AM +0200, Jan Beulich wrote:
> On 25.08.2022 22:36, Demi Marie Obenour wrote:
> > On Thu, Aug 25, 2022 at 09:59:56AM +0200, Jan Beulich wrote:
> >> On 24.08.2022 23:04, Demi Marie Obenour wrote:
> >>> Fix both of these problems by unconditionally setting the memory r
On 25.08.2022 22:36, Demi Marie Obenour wrote:
> On Thu, Aug 25, 2022 at 09:59:56AM +0200, Jan Beulich wrote:
>> On 24.08.2022 23:04, Demi Marie Obenour wrote:
>>> Fix both of these problems by unconditionally setting the memory region
>>> size
>>
>> If you were to report a larger ending address, w
On Thu, Aug 25, 2022 at 09:59:56AM +0200, Jan Beulich wrote:
> On 24.08.2022 23:04, Demi Marie Obenour wrote:
> > The XEN_FW_EFI_MEM_INFO platform op has very surprising behavior: it
> > only sets info->mem.size if the initial value was *larger* than the size
> > of the memory region.
>
> And inte
On 24.08.2022 23:04, Demi Marie Obenour wrote:
> The XEN_FW_EFI_MEM_INFO platform op has very surprising behavior: it
> only sets info->mem.size if the initial value was *larger* than the size
> of the memory region.
And intentionally so - the caller didn't ask for any bigger region,
after all.
>
The XEN_FW_EFI_MEM_INFO platform op has very surprising behavior: it
only sets info->mem.size if the initial value was *larger* than the size
of the memory region. This is not particularly useful and cost me most
of a day of debugging. It also has some integer overflow problems,
though as the dat
