From xen-devel-bounces@lists.xen.org Tue May 20 11:19:43 2014 Received: (at maildrop) by bugs.xenproject.org; 20 May 2014 10:19:43 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1Wmh95-00010f-1E for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Tue, 20 May 2014 11:19:43 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Wmh2J-00014s-RW; Tue, 20 May 2014 10:12:43 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Wmh2J-00014n-3Q for xen-devel@lists.xen.org; Tue, 20 May 2014 10:12:43 +0000 Received: from [85.158.137.68:32794] by server-6.bemta-3.messagelabs.com id 9C/59-00470-A9A2B735; Tue, 20 May 2014 10:12:42 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-16.tower-31.messagelabs.com!1400580761!4975397!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14020 invoked from network); 20 May 2014 10:12:41 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-16.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 20 May 2014 10:12:41 -0000 Received: by mail-wi0-f182.google.com with SMTP id r20so635195wiv.9 for ; Tue, 20 May 2014 03:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VtNDKkkASKeL10z/KcWd/7UKKStdP7Zy+ggblxW8Dck=; b=F45C9YQX2hGlXAsEqaFyafJ3HeOZqJqBKyEqeB1PVb2tE3CMolTDQLyMYns/peucA9 FoYOiAgTL61OF6rXk4dBp9/rjyyYb0fLHZY9/lwvBLKxcbJYfxv8b35EoU724F6xXjKz QtMQWPDKTPooXke8vLyeLlidkP5u6cVk4U59yBpImgHa9j6qqdwJkr5XvNHU4MYiKD3h onkpZuWGo2EscOIt3xq1JkFOeqV/vKsCY71dl2U5kdmmfRea/yqfzpaPIP9LuQc5J1vo GJrrMDVrqqcwnqRBm6jwl3QKqSjPbstndc3sevY5/GvPtaakxXqr0XrrqU2H5fqGVUU+ K8Ug== MIME-Version: 1.0 X-Received: by 10.180.77.70 with SMTP id q6mr3142032wiw.28.1400580761229; Tue, 20 May 2014 03:12:41 -0700 (PDT) Received: by 10.194.14.228 with HTTP; Tue, 20 May 2014 03:12:41 -0700 (PDT) In-Reply-To: <537B1E520200007800013EB7@mail.emea.novell.com> References: <20140210080314.GA758@deinos.phlegethon.org> <20140211090202.GC92054@deinos.phlegethon.org> <20140211115553.GB97288@deinos.phlegethon.org> <52FA2C63020000780011B201@nat28.tlf.novell.com> <52FA480D.9040707@eu.citrix.com> <52FCE8BE.8050105@eu.citrix.com> <52FCF90F020000780011C29A@nat28.tlf.novell.com> <20140213162022.GE82703@deinos.phlegethon.org> <537B1E520200007800013EB7@mail.emea.novell.com> Date: Tue, 20 May 2014 11:12:41 +0100 X-Google-Sender-Auth: x_6yhj41FB8XrEeo-276d3gZstg Message-ID: From: George Dunlap To: Jan Beulich Cc: "andrew.cooper3@citrix.com" , Tim Deegan , "xen-devel@lists.xen.org" , "Keir Fraser\(keir.xen@gmail.com\)" , Jun Nakajima , Yang Z Zhang , Xiantao Zhang Subject: Re: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, May 20, 2014 at 8:20 AM, Jan Beulich wrote: >>>> On 20.05.14 at 05:13, wrote: >> George Dunlap wrote on 2014-05-19: >>> Avoiding these by "hoping" that the guest OS doesn't DMA into a video >>> buffer isn't really robust enough. I think that was Tim and Jan's >> >> Video buffer is only one case. How we can prevent the DMA to other reserved >> region? > > You continue to neglect the difference: Accessing VRAM this way is > legitimate (and potentially useful). And - as just said in the other > reply - ideally we'd also simply ignore accesses to reserved regions > (and in fact we try to, by not immediately bringing down a guest > device doing such). On the other hand, just to play devil's advocate here: Implementing separate IOMMU tables (including superpages) isn't free; it has a non-negligible cost, both in initial developer time, continuing maintenance (code complexity, fixing bugs), extra memory at run-time, &c. Of all the things we could invest that developer time doing, why should we make it possible to DMA into VRAM, rather than doing something else? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel