From xen-devel-bounces@lists.xen.org Tue Feb 11 11:05:02 2014 Received: (at maildrop) by bugs.xenproject.org; 11 Feb 2014 11:05:02 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WDB9C-0003GP-L4 for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Tue, 11 Feb 2014 11:05:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WDB42-0004jw-IR; Tue, 11 Feb 2014 10:59:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WDB41-0004jk-3F for xen-devel@lists.xen.org; Tue, 11 Feb 2014 10:59:41 +0000 Received: from [85.158.139.211:8474] by server-4.bemta-5.messagelabs.com id 38/21-08092-C920AF25; Tue, 11 Feb 2014 10:59:40 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1392116379!3139805!1 X-Originating-IP: [74.125.82.180] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31819 invoked from network); 11 Feb 2014 10:59:39 -0000 Received: from mail-we0-f180.google.com (HELO mail-we0-f180.google.com) (74.125.82.180) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 11 Feb 2014 10:59:39 -0000 Received: by mail-we0-f180.google.com with SMTP id u57so5343779wes.39 for ; Tue, 11 Feb 2014 02:59:39 -0800 (PST) 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=TB7P316J1pcSS18kyFHS1BxOC0lcoZghbl9+FVV1zy0=; b=jXcCtq8mvvnPf/bO0jdG4I3YLB2kk/qnFu2mrxrPBGKJsQjKrSZqCuNQxQ4XAFmrDm f3aX/AIHbWfHal70ZQS5SqUP5ugzWZC6lnfv0E4w01587qJM11BlDlEbTdcVUkGJTBMN JRWA2GqZK4ZhBpnEs5+QYCzyUBbDcjWmaEZvuNDVZn41SyJv022WSzEJjFIXrn5zIyl0 hOKtgTh0JnshVPceWWPjBKvnrLetjtjNxLOnQHHxK7hCCbPpb9ueosNc6OEHlOwdcCTs YMdE29VQzR0mnaad69oC+BDh+vWa/OfJet+GxTTkP/CSZPDN0vUI/syhaFqhXaCA6f1U jZAw== MIME-Version: 1.0 X-Received: by 10.194.22.129 with SMTP id d1mr26456865wjf.22.1392116379048; Tue, 11 Feb 2014 02:59:39 -0800 (PST) Received: by 10.194.75.163 with HTTP; Tue, 11 Feb 2014 02:59:38 -0800 (PST) In-Reply-To: <20140211090202.GC92054@deinos.phlegethon.org> References: <1392012840-22555-1-git-send-email-yang.z.zhang@intel.com> <20140210080314.GA758@deinos.phlegethon.org> <20140211090202.GC92054@deinos.phlegethon.org> Date: Tue, 11 Feb 2014 10:59:38 +0000 X-Google-Sender-Auth: XLtDqNu4uglBFu9BP6ribMgEknQ Message-ID: From: George Dunlap To: Tim Deegan Cc: "Zhang, Yang Z" , "andrew.cooper3@citrix.com" , "JBeulich@suse.com" , "Zhang, Xiantao" , "xen-devel@lists.xen.org" 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, Feb 11, 2014 at 9:02 AM, Tim Deegan wrote: > At 08:15 +0000 on 10 Feb (1392016516), Zhang, Yang Z wrote: >> Tim Deegan wrote on 2014-02-10: >> > At 14:14 +0800 on 10 Feb (1392038040), Yang Zhang wrote: >> >> From: Yang Zhang >> >> >> >> When enabling log dirty mode, it sets all guest's memory to readonly. >> >> And in HAP enabled domain, it modifies all EPT entries to clear >> >> write bit to make sure it is readonly. This will cause problem if >> >> VT-d shares page table with EPT: the device may issue a DMA write >> >> request, then VT-d engine tells it the target memory is readonly and >> >> result in VT-d >> > fault. >> > >> > So that's a problem even if only the VGA framebuffer is being tracked >> > -- DMA from a passthrough device will either cause a spurious error or >> > fail to update the dirt bitmap. >> >> Do you mean the VGA frambuffer will be used as DMA buffer in guest? If yes, I think it's guest's responsibility to ensure it never happens. >> > > I don't think that works. We can't expect arbitrary OSes to (a) know > they're running on Xen and (b) know that that means they can't DMA to > or from their framebuffers. > >> Without VT-d and EPT share page, we still cannot track the memory >> updating from DMA. > > Yeah, but at least we don't risk crashing the _host_ by throwing DMA > failures around. What I'm missing here is what you think a proper solution is. It seems we have: A. Share EPT/IOMMU tables, only do log-dirty tracking on the buffer being tracked, and hope the guest doesn't DMA into video ram; DMA causes IOMMU fault. (This really shouldn't crash the host under normal circumstances; if it does it's a hardware bug.) B. Never share EPT/IOMMU tables, and hope the guest doesn't DMA into video ram. DMA causes missed update to dirty bitmap, which will hopefully just cause screen corruption. C. Do buffer scanning rather than dirty vram tracking (SLOW) D. Don't allow both a virtual video card and pass-through Given that most operating systems will probably *not* DMA into video ram, and that an IOMMU fault isn't *supposed* to be able to crash the host, 'A' seems like the most reasonable option to me. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel