On Fri, Jan 29, 2021 at 5:51 AM Pavel Tatashin
wrote:
>
> > Since we last talked about this the enabling for EFI "Special Purpose"
> > / Soft Reserved Memory has gone upstream and instantiates device-dax
> > instances for address ranges marked with EFI_MEMORY_SP attribute.
> > Critically this way
On Fri, Jan 29, 2021 at 2:12 PM Pavel Tatashin
wrote:
>
> On Fri, Jan 29, 2021 at 2:06 PM Pavel Tatashin
> wrote:
> >
> > > > Definitely, but we should try figuring out what's going on here. I
> > > > assume on x86-64 it behaves differently?
> > >
> > > Yes, we should root cause. I highly suspect
On Fri, Jan 29, 2021 at 2:06 PM Pavel Tatashin
wrote:
>
> > > Definitely, but we should try figuring out what's going on here. I
> > > assume on x86-64 it behaves differently?
> >
> > Yes, we should root cause. I highly suspect that there is somewhere
> > alignment miscalculations happen that caus
> > Definitely, but we should try figuring out what's going on here. I
> > assume on x86-64 it behaves differently?
>
> Yes, we should root cause. I highly suspect that there is somewhere
> alignment miscalculations happen that cause this memory waste with the
> offset 16M. I am also not sure why t
On 1/29/21 4:32 PM, Pavel Tatashin wrote:
> On Fri, Jan 29, 2021 at 9:51 AM Joao Martins
> wrote:
>>
>> Hey Pavel,
>>
>> On 1/29/21 1:50 PM, Pavel Tatashin wrote:
Since we last talked about this the enabling for EFI "Special Purpose"
/ Soft Reserved Memory has gone upstream and insta
On Fri, Jan 29, 2021 at 9:51 AM Joao Martins wrote:
>
> Hey Pavel,
>
> On 1/29/21 1:50 PM, Pavel Tatashin wrote:
> >> Since we last talked about this the enabling for EFI "Special Purpose"
> >> / Soft Reserved Memory has gone upstream and instantiates device-dax
> >> instances for address ranges m
On Fri, Jan 29, 2021 at 8:19 AM David Hildenbrand wrote:
>
> On 29.01.21 03:06, Pavel Tatashin wrote:
> >>> Might be related to the broken custom pfn_valid() implementation for
> >>> ZONE_DEVICE.
> >>>
> >>> https://lkml.kernel.org/r/1608621144-4001-1-git-send-email-anshuman.khand...@arm.com
> >>>
On Wed, Jan 27, 2021 at 1:50 PM Pavel Tatashin
wrote:
>
> On Wed, Jan 27, 2021 at 4:09 PM David Hildenbrand wrote:
> >
> > On 27.01.21 21:43, Pavel Tatashin wrote:
> > > This is something that Dan Williams and I discussed off the mailing
> > > list sometime ago, but I want to have a broader discu
> > Might be related to the broken custom pfn_valid() implementation for
> > ZONE_DEVICE.
> >
> > https://lkml.kernel.org/r/1608621144-4001-1-git-send-email-anshuman.khand...@arm.com
> >
> > And essentially ignoring sub-section data in there for now as well (but
> > might not be that relevant yet).
One issue usually is that often firmware can allocate from available
system RAM and/or modify/initialize it. I assume you're running some
custom firmware :)
We have a special firmware that does not touch the last 2G of physical
memory for its allocations :)
Fancy :)
[...]
Personally, I thi
On Wed, Jan 27, 2021 at 5:18 PM David Hildenbrand wrote:
>
> >> Ordinary reboots or kexec-style reboots? I assume the latter, because
> >> otherwise there is no guarantee about persistence, right?
> >
> > Both, our firmware supports cold and warm reboot. When we do warm
> > reboot, memory content
Ordinary reboots or kexec-style reboots? I assume the latter, because
otherwise there is no guarantee about persistence, right?
Both, our firmware supports cold and warm reboot. When we do warm
reboot, memory content is not initialized. However, for performance
reasons, we mostly do kexec reboot
On Wed, Jan 27, 2021 at 4:09 PM David Hildenbrand wrote:
>
> On 27.01.21 21:43, Pavel Tatashin wrote:
> > This is something that Dan Williams and I discussed off the mailing
> > list sometime ago, but I want to have a broader discussion about this
> > problem so I could send out a fix that would b
On 27.01.21 21:43, Pavel Tatashin wrote:
This is something that Dan Williams and I discussed off the mailing
list sometime ago, but I want to have a broader discussion about this
problem so I could send out a fix that would be acceptable.
We have a 2G pmem device that is carved out of regular me
This is something that Dan Williams and I discussed off the mailing
list sometime ago, but I want to have a broader discussion about this
problem so I could send out a fix that would be acceptable.
We have a 2G pmem device that is carved out of regular memory that we
use to pass data across reboot
15 matches
Mail list logo
