Re: [Xen-devel] Trapping I/O accesses of a driver domain

["Olatunji Ruwase" <oor@xxxxxxxxxx>]

>> 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