Re: [PATCH] VMI: remove CONFIG_DEBUG_PAGE_TYPE and associated bitrotted code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Zachary Amsden wrote:
I though about it, but it gets really ugly. You need wrappers for all the MMU ops in pvops generic code, which means either another layer of wrappers or a bunch of CONFIG_DEBUG_PARAVIRT

Oh, yes, more wrappers please! We could do it at the paravirt_ops level: set up your pv_ops, then call paravirt_debug_mmuops(), which would save away your ops and replace them with wrappers. That basic structure would lend itself to all kinds of paravirt-level debugging tools.

It would be a bit more elegant if we had mmu_ops. Maybe we should do that splitup before 64bit?

only things that are easy to break because they also depend on PAE vs. non-PAE.

Hm, would they? Would they need to inspect the content of the pte_t (etc), or just look at the struct page for the page being updated? (pmd operations being a bit more awkward, of course.)

It's doable, though, and might even be extensible to s390 for CMM page type debugging, as well as descriptor type tracking and enforcement of page isolation of GDTs.

Page state tracking could track -

PAGE_ZERO, PAGE_UNUSED, PAGE_STABLE, PAGE_VOLATILE, PAGE_POTENTIALLY_VOLATILE, PAGE_L1{2/3/4}, PAGE_LDT, PAGE_GDT,

actually, no this seems silly, since we'd just be duplicating bits for the page types, so the only debug benefit is ensuring the intersection of volatile and L{1/2/3/4} is nil, which is already trivially verifiable by inspection.

Well, I have to say that keeping the hypervisor hints in sync with the actual kernel-level page state worries me, so any debug tools which could help there would be good. This seems like it should be the right place to do it, but I can't say I've thought about it in any detail.

Of course, if it *is* helpful to the page hinting patches, then it suggests that it's a facility with wider scope than pv-ops.

   J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux