From xen-devel-bounces@lists.xen.org Mon Jun 02 16:11:23 2014 Received: (at maildrop) by bugs.xenproject.org; 2 Jun 2014 15:11:23 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WrTtS-0007tZ-VO for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Mon, 02 Jun 2014 16:11:22 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WrTm9-00023S-To; Mon, 02 Jun 2014 15:03:49 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WrTm8-00023L-J7 for xen-devel@lists.xen.org; Mon, 02 Jun 2014 15:03:48 +0000 Received: from [85.158.137.68:63350] by server-10.bemta-3.messagelabs.com id D4/1B-16608-3529C835; Mon, 02 Jun 2014 15:03:47 +0000 X-Env-Sender: George.Dunlap@citrix.com X-Msg-Ref: server-6.tower-31.messagelabs.com!1401721423!3085772!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.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 756 invoked from network); 2 Jun 2014 15:03:45 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 2 Jun 2014 15:03:45 -0000 X-IronPort-AV: E=Sophos;i="4.98,957,1392163200"; d="scan'208";a="138181111" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 02 Jun 2014 15:03:45 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.3.181.6; Mon, 2 Jun 2014 11:03:43 -0400 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1WrTm2-0006uK-Pz; Mon, 02 Jun 2014 16:03:42 +0100 Message-ID: <538C9238.5080701@eu.citrix.com> Date: Mon, 2 Jun 2014 16:03:20 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jan Beulich References: <20140210080314.GA758@deinos.phlegethon.org> <537B1E520200007800013EB7@mail.emea.novell.com> <537B4EA70200007800014085@mail.emea.novell.com> <537C769B02000078000145C2@mail.emea.novell.com> <537F09EC020000780001530D@mail.emea.novell.com> <53831FD902000078000159F9@mail.emea.novell.com> <538C3BE40200007800016AE1@mail.emea.novell.com> <538CA5E80200007800016E34@mail.emea.novell.com> In-Reply-To: <538CA5E80200007800016E34@mail.emea.novell.com> X-DLP: MIA1 Cc: "andrew.cooper3@citrix.com" , Tim Deegan , "xen-devel@lists.xen.org" , "KeirFraser\(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-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 06/02/2014 03:27 PM, Jan Beulich wrote: >>>> On 02.06.14 at 16:06, wrote: >> On Mon, Jun 2, 2014 at 7:55 AM, Jan Beulich wrote: >>>>>> On 31.05.14 at 03:26, wrote: >>>> On Mon, May 26, 2014 at 2:04 AM, Jan Beulich wrote: >>>>>>>> On 26.05.14 at 10:16, wrote: >>>>>> Jan Beulich wrote on 2014-05-23: >>>>>>> Btw., I think I just spotted a second thing not working without split page >>>>>> tables: >>>>>>> mem-access (which doesn't and imo shouldn't depend on !need_iommu(), >>>>>>> other than mem-sharing and mem-paging) likewise has the potential of >>>>>>> creating entries resulting in IOMMU faults. >>>>>>> >>>>>> I don't know what mem-access is? Do you mean Xenaccess? If not, can you >>>>>> elaborate it or provide a link to help me to understand how it works? >>>>> The (example) tool indeed is named xen-access. See XENMEM_access_op >>>>> (used to be HVMOP_{get,set}_mem_access). >>>>> >>>> The tool xen-access is located in tools/tests, and I think that this >>>> is used mostly by developers who know what they are doing. >>> The tool is, indeed. But the underlying feature clearly isn't limited >>> to or solely intended for developers. >>> >>>> If we had separate VT-d page tables, they might observe confusing >>>> results; even if they write-protect pages, somebody (i.e. I/O devices) >>>> modifies those pages. >>>> To me, observing IOMMU faults seems consistent with the consequence of >>>> changes to guest memory permission. >>> And I would agree if these faults were restartable. You're certainly >>> aware that a not too large amount of faults within a reasonably short >>> period of time will lead to the device being turned off, with quite likely >>> fatal consequences to the guest. >> Sure -- but there are a number of features (PoD, paging, page sharing, >> even migration) which are incompatible with pass-through, and the user >> is simply not allowed to use them together. Why not just add this one >> to the list? > Considering that mem-access came at about the same time or even > later than mem-paging and mem-sharing, I was silently assuming that > it wasn't enforcing the same restrictions as the other two for a reason. > Maybe it was just forgotten... Well one can certainly imagine someone wanting to run it in that mode, and "knowing" that it would be safe because they were going to be careful not going to use memaccess on pages on which a DMA was going to happen. I think in that situation, a developer would probably want to know that their assumption was wrong immediately (by having the IOMMU fault perhaps crash the domain), than have to figure out that their assumption was wrong by having unexplainable results. If memaccess + passthru is enabled by default at the moment, there may be an argument for disabling it by default, perhaps with an override for those who want the ability to shoot themselves in the foot. But I don't think that silent violations of the memaccess "promise" is better than just having the IOMMU faults; so I don't think that's an argument for implementing non-shared IOMMU superpages. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel