On Fri, Nov 07, 2014 at 12:37:11PM -0800, Mario Smarduch wrote: > Hi Magnus, > so I think Christoffer answered the root cause, so not much > to add from my end. > > I was under the impression you could grab huge chunk of memory > early during initialization while memory is not fragmented. > > But if it's so big and contiguous, that you have to reserve > then I don't know. > > On 11/07/2014 01:35 AM, Magnus Karlsson wrote: > > Mario, > > > > That is exactly what I am using, which is good since it means I am not > > doing something completely silly. The problem I am having is that > > kvm_is_mmio_pfn() returns true for my networking device memory region > > because PageReserved() returns true as the (in the Qemu driver mmaped) > > physical memory region was carved out of DRAM using a memreserve in the > > device tree. This region is huge and needs to be consecutive. > > > > Is it a valid assumption that all Reserved pages are supposed to be > > treated as non-coherent device pages (as it indirectly sets mem_type = > > PAGE_S2_DEVICE in user_mem_abort)? > > No if I had to guess PageReserved() has double meaning here and fails > in your use case which is legitimate. Another way to identify device > memory may be needed. > > > The git log comment for the if > > statement in user_mem_abort that causes my problems fits perfectly with > > what I want to achieve, though my mem region is cache coherent normal > > memory, not non-coherent device memory. Is there a way to communicate > > what type of memory I have mapped via VFIO or /dev/mem that this code > > could use? > > Not sure but it doesn't appear like it can, 2nd stage page fault handler > just defaults in your case to S2_DEVICE due to page type attributes. > > There was a discussion some time back to relax stage2 to PAGE_S2 (or > I think a patch was already posted) and let stage 1 determine the > attributes. > That would allow you to set your memory region cacheable. But there was > some > security hole for GIC where other guests can access each others GIC ranges. > Perhaps just making GIC range S2_DEVICE may work but this needs maintainers > to resolve these issues. You might have to look for some workaround. > This is not just for the GIC, it's for any bus mastering device. -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
