[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Trapping I/O accesses of a driver domain
>> I am happy to modify the 2.16.8-xen to cover the outstanding cases, >> except this is a fundamentally flawed approach. Can you elaborate the > > Huh? What is the flawed approach? > Pardon the typo, that was meant to ask if the following idea was flawed. Enable trapping on accesses to ioremap'd pages by (1) mark their PTEs with _PAGE_IO before they are passed to HYPERVISOR_mmu_update(), (2) in xen (do_mmu_update()) mark pages for which _PAGE_IO is set not present. It seemed to me that 2.6.18-xen always does (1), but you clarified that it was not the case. So I wanted to know in which scenarios could an ioremap'd PTE be passed to xen without having _PAGE_IO set. And conversely, in which scenarios could a non-ioremap'd page PTE be passed to xen with _PAGE_IO set. However, given your comment about xen being unware of _PAGE_IO, the converse case probably does not matter. With knowledge of these scenerios, then perhaps I could modify both 2.6.18-xen and xen and use _PAGE_IO markings to achieve my goal of causing traps on ioremap'd page accesses. > So it sounds like you are concentrating on making this work in the dom0, > domU, not in the hypervisor. In which case you can ignore the E820. > I would prefer modifying only the hypervisor if possible, so your suggestion of checking against the PCI gap space in E820 sounds relevant. In fact it seems that the machine address(mfn) argument passed to ioremap*() should fall into the PCI gap space. I will investigate this assumption. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |