From xen-devel-bounces@lists.xen.org Wed May 21 11:05:13 2014 Received: (at maildrop) by bugs.xenproject.org; 21 May 2014 10:05:13 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1Wn3Ob-0007cc-AW for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Wed, 21 May 2014 11:05:13 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Wn3Hh-0002TZ-O9; Wed, 21 May 2014 09:58:05 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Wn3Hg-0002TR-1q for xen-devel@lists.xen.org; Wed, 21 May 2014 09:58:04 +0000 Received: from [193.109.254.147:62658] by server-2.bemta-14.messagelabs.com id CA/3D-21684-BA87C735; Wed, 21 May 2014 09:58:03 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1400666282!6188996!1 X-Originating-IP: [130.57.118.101] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16529 invoked from network); 21 May 2014 09:58:02 -0000 Received: from mail.emea.novell.com (HELO mail.emea.novell.com) (130.57.118.101) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 May 2014 09:58:02 -0000 Received: from EMEA1-MTA by mail.emea.novell.com with Novell_GroupWise; Wed, 21 May 2014 10:58:01 +0100 Message-Id: <537C94C902000078000146F5@mail.emea.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.0.0 Date: Wed, 21 May 2014 10:58:01 +0100 From: "Jan Beulich" To: "Yang Z Zhang" 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> <537B4EA70200007800014085@mail.emea.novell.com> <537C769B02000078000145C2@mail.emea.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Disposition: inline Cc: George Dunlap , "andrew.cooper3@citrix.com" , Tim Deegan , "xen-devel@lists.xen.org" , "KeirFraser\(keir.xen@gmail.com\)" , Jun Nakajima , 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 21.05.14 at 10:37, wrote: > Jan Beulich wrote on 2014-05-21: >>>>> On 21.05.14 at 03:02, wrote: >>> Jan Beulich wrote on 2014-05-20: >>>>>>> On 20.05.14 at 12:12, wrote: >>>>> 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 >>> >>> Can you give an example of what legitmate case you are mentioned twice(You >>> mentioned it also in other reply)? >> >> What's wrong with loading some graphics data right from an I/O device >> (disk, network) into the frame buffer? > > Yes, it is ok. But we are talking about the DMA access to a 'readonly' > buffer. It is totally a wrong usage model to me. What read-only buffer are you referring to? From guest perspective, nothing that gets marked read-only due to log-dirty handling really is read-only. The fact that migration doesn't work due to this with an assigned device can be excused by the handling of such an assigned device not being implemented anyway. But the fact that behind the scenes VRAM gets marked read-only should be (but isn't) entirely transparent to the guest. I'm not going to reply to the rest of your mail, both because I'm getting the impression that we're moving in circles, and because I might become impolite otherwise. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel