[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 10:25:56PM -0500, Olatunji Ruwase wrote:
> >> 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?
> >
>  My work is based on simulated hardware logging and a significantly
>  modified FC5, porting the kernel modifications to FC6 is significantly
>  than to more recent kernels like FC16.

You could do this on real hardware. Say get an machine with IOMMU
(like a TA890FXE) and use the AMD VI to trap you on all the IOMMU
(so DMA) operations. ..

Thought it might be worth reading first the AMD VI spec whether you can
trap on all DMA operations.
> 
> >> 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.
> >
>  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?

>  ioremap scenarios for pte are not marked _PAGE_IO. Are the requirements
>  documented?

The _PAGE_IO is a Linux kernel concept used to figure if the PTE contains
the MFN or  PFN value. I don't think the hypervisor cares about it.

> 
> >> 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?
> >>
>   I m not familiar with E820, but will explore it, thanks.

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.

> 
> >>  hypercall informing Xen that the locations are used for I/O. I am
> >> probably
> >
> > Right.
> >
> 
>  Thanks for the response.
> 
> 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®.