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

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



On Thu, Nov 10, 2011 at 05:57:27PM -0500, Olatunji Ruwase wrote:
> Hi,
>  I am a graduate student working on dynamic correctness checking of kernel
>  mode device drivers. I want to detect/trap accesses from a Linux driver
>  to device accessible locations (e.g ioremap'd, dma_* locations), and
>  I am exploring the possibility of using Xen for this. I am using x86 PV
>  Xen-3.3 with a dom0 and driver domU both running linux-2.6.18-xen. For
>  various reasons HVM Xen is not suitable for my work.

Um, why not use something more recent. Like Ubuntu or Fedora Core 16?
> 
>  The idea is to use page faults to detect the I/O accesses of the driver
>  by marking the affected pages not present in the page tables. For
>  ioremap'd pages, this seems pretty straightforward since the ptes are
>  marked with _PAGE_IO before they are passed to Xen. And so it seems

Not all the time and it is not a requirement.
>  modifying do_mmu_update () to detect and mark such ptes not present should
>  work. Is this a reasonable approach ?.

What about just checking the MFNs against the ones in the E820 that
are in the PCI gap space?
> 
>  Detecting accesses to dma mapped (dma_alloc_coherent, dma_map_single)
>  locations seems more difficult because, as far as I can tell there is no
>  hypercall informing Xen that the locations are used for I/O. I am probably

Right.
>  misunderstanding how this works and would appreciate clarifications.
> 
>  Thank you,
> 
> tunji
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.