Hi - On 2018-12-04 at 14:51 Alexander Duyck <alexander.h.duyck@xxxxxxxxxxxxxxx> wrote: [snip] > > I think the confusion arises from the fact that there are a few MMIO > > 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 > touched. > > 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. Barret
