From xen-devel-bounces@lists.xen.org Thu Feb 13 15:52:03 2014 Received: (at maildrop) by bugs.xenproject.org; 13 Feb 2014 15:52:03 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WDya3-0002Cb-0u for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Thu, 13 Feb 2014 15:52:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WDyUZ-0002YG-ND; Thu, 13 Feb 2014 15:46:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WDyUY-0002Y9-9v for xen-devel@lists.xen.org; Thu, 13 Feb 2014 15:46:22 +0000 Received: from [85.158.143.35:10510] by server-3.bemta-4.messagelabs.com id 27/9F-11539-DC8ECF25; Thu, 13 Feb 2014 15:46:21 +0000 X-Env-Sender: George.Dunlap@citrix.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1392306379!5466848!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9630 invoked from network); 13 Feb 2014 15:46:20 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 13 Feb 2014 15:46:20 -0000 X-IronPort-AV: E=Sophos;i="4.95,839,1384300800"; d="scan'208";a="100487545" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 13 Feb 2014 15:46:18 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.4; Thu, 13 Feb 2014 10:46:18 -0500 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1WDyUU-0002LB-29; Thu, 13 Feb 2014 15:46:18 +0000 Message-ID: <52FCE8BE.8050105@eu.citrix.com> Date: Thu, 13 Feb 2014 15:46:06 +0000 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Zhang, Yang Z" , Jan Beulich , Tim Deegan References: <1392012840-22555-1-git-send-email-yang.z.zhang@intel.com> <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> In-Reply-To: X-DLP: MIA2 Cc: "andrew.cooper3@citrix.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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/12/2014 12:53 AM, Zhang, Yang Z wrote: > George Dunlap wrote on 2014-02-11: >> On 02/11/2014 12:57 PM, Jan Beulich wrote: >>>>>> On 11.02.14 at 12:55, Tim Deegan wrote: >>>> At 10:59 +0000 on 11 Feb (1392112778), George Dunlap wrote: >>>>> What I'm missing here is what you think a proper solution is. >>>> A _proper_ solution would be for the IOMMU h/w to allow restartable >>>> faults, so that we can do all the usual fault-driven virtual memory >>>> operations with DMA. :) In the meantime... >>> Or maintaining the A/D bits for IOMMU side accesses too. >>> >>>>> 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.) >>>> Note "hope" and "shouldn't" there. :) >>>> >>>>> 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. >>>> Yep. At a cost of about 0.2% in space and some extra bookkeeping >>>> (for VMs that actually have devices passed through to them). >>>> The extra bookkeeping could be expensive in some cases, but >>>> basically all of those cases are already incompatible with IOMMU. >>>> >>>>> C. Do buffer scanning rather than dirty vram tracking (SLOW) D. >>>>> Don't allow both a virtual video card and pass-through >>>> E. Share EPT and IOMMU tables until someone turns on log-dirty mode >>>> and then split them out. That one >>> Wouldn't that be problematic in terms of memory being available, >>> namely when using ballooning in Dom0? >>> >>>>> 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. >>>> Meh, OK. I prefer 'B' but 'A' is better than nothing, I guess, and >>>> seems to have most support from other people. On that basis this >>>> patch can have my Ack. >>> I too would consider B better than A. >> I think I got a bit distracted with the "A isn't really so bad" thing. >> Actually, if the overhead of not sharing tables isn't very high, then >> B isn't such a bad option. In fact, B is what I expected Yang to >> submit when he originally described the problem. > Actually, the first solution came to my mind is B. Then I realized that even chose B, we still cannot track the memory updating from DMA(even with A/D bit, it still a problem). Also, considering the current usage case of log dirty in Xen(only vram tracking has problem), I though A is better.: Hypervisor only need to track the vram change. If a malicious guest try to DMA to vram range, it only crashed himself (This should be reasonable). > >> I was going to say, from a release perspective, B is probably the >> safest option for now. But on the other hand, if we've been testing >> sharing all this time, maybe switching back over to non-sharing whole-hog has the higher risk? > Another problem with B is that current VT-d large paging supporting relies on the sharing EPT and VT-d page table. This means if we choose B, then we need to re-enable VT-d large page. This would be a huge performance impaction for Xen 4.4 on using VT-d solution. OK -- if that's the case, then it definitely tips the balance back to A. Unless Tim or Jan disagrees, can one of you two check it in? Don't rush your judgement; but it would be nice to have this in before RC4, which would mean checking it in today preferrably, or early tomorrow at the latest. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel