On 2018-12-04 at 14:51 Alexander Duyck
> I think the confusion arises from the fact that there are a few
> resources with a struct page and all the rest MMIO resources without.
> The problem comes from the coarse definition of pfn_valid(), it may
> return 'true' for things that are not System-RAM, because pfn_valid()
> may be something as simplistic as a single "address < X" check. Then
> PageReserved is a fallback to clarify the pfn_valid() result. The
> typical case is that MMIO space is not caught up in this linear map
> confusion. An MMIO address may or may not have an associated 'struct
> page' and in most cases it does not.
Okay. I think I understand this somewhat now. So the page might be
physically there, but with the reserved bit it is not supposed to be
My main concern with just dropping the bit is that we start seeing some
other uses that I was not certain what the impact would be. For example
the functions like kvm_set_pfn_accessed start going in and manipulating
things that I am not sure should be messed with for a DAX page.
One thing regarding the accessed and dirty bits is that we might want
to have DAX pages marked dirty/accessed, even if we can't LRU-reclaim
or swap them. I don't have a real example and I'm fairly ignorant
about the specifics here. But one possibility would be using the A/D
bits to detect changes to a guest's memory for VM migration. Maybe
there would be issues with KSM too.