Re: [Xen-devel] QEMU and hypervisor DMA understanding. Want to track DMA operations on QEMU devices.

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Jul 01, 2010 at 11:38:31AM +0530, Abhinav Srivastava wrote:
> Hi Konrad,
> 
> Thanks for your reply. You reply was very helpful in understanding the 
> DMA mechanism. The goal of my project is to intercept all DMA requests issued 
> by guest HVM domains and check for the memory regions (guest physical 
> address) mentioned in those requests. This will help detect malicious DMA 
> writes specified by malicious drivers. I am trying 
> to achieve this without VT-d support on intel processors.
> 
> I have some follow up questions:
> 
> 1. When a guest HVM domain requests DMA operations, it specifies guest 
> physical addresses. Who converts guest physical to host physical addresses? 
> Does this conversion happen in Dom0 or hypervisor? Which code path should I 
> be looking at?

Hypervisor. Shadow page table. George might have a document tucked away
explaining how the shadow page table works.

> 
> 2. I am looking at the place where I can hook into so that I could intercept 
> all DMA requests issued by the HVM guest and verify the addresses? Is there 
> any place where all DMA requests come and then routed to specific devices in 
> QEMU emulation code? If I could hook at the common place, it would be easier 
> to intercept rather putting the check 
> in each device specific files.

Ian might know this better..
> 
> I really appreciate for your time.
> 
> Thanks,
> Abhinav
> 
> --- On Wed, 30/6/10, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> 
> > From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > Subject: Re: [Xen-devel] DMA understanding
> > To: "Abhinav Srivastava" <abhinavs_iitkgp@xxxxxxxxxxx>
> > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> > Date: Wednesday, 30 June, 2010, 9:32 PM
> > On Tue, Jun 29, 2010 at 12:10:48AM
> > +0530, Abhinav Srivastava wrote:
> > > 
> > > Hi there,
> > > 
> > > I am trying to understand how an HVM guest domain
> > performs its DMA operations, and how this DMA operations are
> > intercepted by the Xen. I wanted to understand both the code
> > path with and without Vt-d support (for intel processors).
> > On looking inside the Xen code, I found that iommu code is
> > inside the vmx/vtd/ directory only. By seeing the code, my
> > understanding is that when Vt-d is enabled, iommu.c and
> > dmar.c inside the vtd directory is the place to look for DMA
> > operations. However, I do not understand which code path
> > inside the hypervisor is getting used in case of Vt-d is
> > disabled?  How does Xen intercept guest DMA operations
> > in this case? I am using Xen 3.3 version for my project (I
> > admit that it is very old version).
> > 
> > Lets start without the Intel VT-d or AMD Vi in the
> > picture.
> > 
> > When the QEMU boots up an HVM guest, it emulates everything
> > the guest
> > sees or does. Which means that when the guest decides to
> > use the
> > IDE controller to do DMA operations, QEMU decodes that
> > operation
> > (look in hw/ide.c, search for 'WIN_READDMA') and it follows
> > it
> > through by setting up a callback mechanism that ends up
> > fetching
> > the data from wherever the guest disk and then triggering
> > an interrupt
> > so that the guest noticies that the DMA finished.
> > 
> > So in essence the hypervisor does not deal with guest DMA
> > at all.
> > 
> > When you insert an Intel VT-d or AMD Vi chipset you have
> > the option
> > of passing in a native PCI device to the guest. If you
> > don't pass
> > in a PCI device then you are still using the old
> > mechanism.
> > 
> > 
> > _______________________________________________
> > 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