From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olatunji Ruwase <oor@cs.cmu.edu>
Cc: xen-devel@lists.xensource.com
Subject: Re: Trapping I/O accesses of a driver domain
Date: Fri, 11 Nov 2011 10:26:19 -0500 [thread overview]
Message-ID: <20111111152619.GB4712@phenom.dumpdata.com> (raw)
In-Reply-To: <60193.71.199.121.110.1320981956.squirrel@webmail.cs.cmu.edu>
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@lists.xensource.com
> http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2011-11-11 15:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-10 22:57 Trapping I/O accesses of a driver domain Olatunji Ruwase
2011-11-10 23:27 ` Konrad Rzeszutek Wilk
2011-11-11 3:25 ` Olatunji Ruwase
2011-11-11 15:26 ` Konrad Rzeszutek Wilk [this message]
2011-11-11 16:14 ` Tim Deegan
2011-11-11 19:27 ` Olatunji Ruwase
-- strict thread matches above, loose matches on Subject: below --
2011-11-10 21:32 Olatunji Ruwase
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111111152619.GB4712@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=oor@cs.cmu.edu \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.