On Tue, Oct 13, 2020 at 3:27 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 08/10/20 09:53, yulei.kernel@xxxxxxxxx wrote: > > From: Yulei Zhang <yuleixzhang@xxxxxxxxxxx> > > > > x86 pat uses 'struct page' by only checking if it's system ram, > > however it is not true if dmem is used, let's teach pat to > > recognize this case if it is ram but it is !pfn_valid() > > > > We always use WB for dmem and any attempt to change this > > behavior will be rejected and WARN_ON is triggered > > > > Signed-off-by: Xiao Guangrong <gloryxiao@xxxxxxxxxxx> > > Signed-off-by: Yulei Zhang <yuleixzhang@xxxxxxxxxxx> > > Hooks like these will make it very hard to merge this series. > > I like the idea of struct page-backed memory, but this is a lot of code > and I wonder if it's worth adding all these complications. > > One can already use mem= to remove the "struct page" cost for most of > the host memory, and manage the allocation of the remaining memory in > userspace with /dev/mem. What is the advantage of doing this in the kernel? > > Paolo > hi Paolo，as far as I know there are a few limitations to play with /dev/mem in this case. 1. access to /dev/men is restricted due to the security requirement, but usually our virtual machines are unprivileged processes. 2. what we get from /dev/mem is a whole block of memory, as dynamic VMs running on /dev/mem will cause memory fragment, it needs extra logic to manage the allocation and recovery to avoid wasted memory. dmemfs can support this and also leverage the kernel tlb management. 3. it needs to support hugepage with different page size granularity. 4. MCE recovery capability is also required.
