WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] DMA understanding

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] DMA understanding
From: Abhinav Srivastava <abhinavs_iitkgp@xxxxxxxxxxx>
Date: Thu, 1 Jul 2010 11:38:31 +0530 (IST)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 30 Jun 2010 23:09:29 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1277964511; bh=0Yp/5k/TW357b6b77EiYHQ+OZuLdr4xLTVPL2e1NMQA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=b/4kz/+Xhy27OZ8rRfw64oqQm7DugYmGuTailJ6fYsF0vra//d8qCEeh2Tqk0uRycrW5NhN42w9KtaluW+AfY6K4kSAOR7jJu1MH6L5iAxnavtwbBiS1yvPYROOUF+HC0pWbfVBR9JGizkI8G2+YqYnU/cO9MJR5ZWSd6/LT9Gk=
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BA9xOePb9/WDopDDcROS92jxfPjI6SrqgmvtxfT7f69zT9k4pFQhY42ioKMFN/BcBOgUNMT1361XLQYFhKGAeW2bGRS3VjYpleYBgFlr319+Np0w9WXC9Dg+CGB28lgiUxO/3hYy2d/nfQ0jAFildQU2ilRM+0Q+eOLyDGprfb0=;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100630160222.GC5100@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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?

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.

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

<Prev in Thread] Current Thread [Next in Thread>