From xen-devel-bounces@lists.xen.org Mon Jun 02 15:13:25 2014 Received: (at maildrop) by bugs.xenproject.org; 2 Jun 2014 14:13:25 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WrSzN-0007GL-Qy for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Mon, 02 Jun 2014 15:13:25 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WrSsX-0004YL-8b; Mon, 02 Jun 2014 14:06:21 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WrSsV-0004YE-Lu for xen-devel@lists.xen.org; Mon, 02 Jun 2014 14:06:19 +0000 Received: from [85.158.137.68:46890] by server-17.bemta-3.messagelabs.com id E1/63-22741-AD48C835; Mon, 02 Jun 2014 14:06:18 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-14.tower-31.messagelabs.com!1401717978!5066793!1 X-Originating-IP: [74.125.82.177] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10700 invoked from network); 2 Jun 2014 14:06:18 -0000 Received: from mail-we0-f177.google.com (HELO mail-we0-f177.google.com) (74.125.82.177) by server-14.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 2 Jun 2014 14:06:18 -0000 Received: by mail-we0-f177.google.com with SMTP id x48so5042739wes.8 for ; Mon, 02 Jun 2014 07:06:17 -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=ArR3EtgpOSYi80jT8Mo3g+vxdou23MGuA8JGtypgAR0=; b=PzxPDmI5bSPXxDcP3HbPCRZcv1Q5zZDtiGyDM8WCdIiVZf+MOd82cK7X/7w68os23P nMS465QqkT5iMHb1/+U2/rkjvFE0pq2AhTaK4C41Pk5vR4GzIHebbPOVLNXSt4lbENge etZrybyV2ox7krHkGJ15DdPxpI/ExNaisB8/xnIDuS4KujmSsz4/nd1JGHSN/PoOpkwO 7ziiD0z186jX1CkKNILBkTKnSCxmXx3oJZvmKra741Ftu/S4+DHfQe2qwmpRH+vmM17T 0z80TiGii12OOAe0qRflj3PZo/XCsHZ5N2Pfame/WJbPACQUfe1xY2V0BXN9yqE3ito0 QQHQ== MIME-Version: 1.0 X-Received: by 10.180.189.76 with SMTP id gg12mr22597188wic.28.1401717977655; Mon, 02 Jun 2014 07:06:17 -0700 (PDT) Received: by 10.194.14.228 with HTTP; Mon, 2 Jun 2014 07:06:17 -0700 (PDT) In-Reply-To: <538C3BE40200007800016AE1@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> <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> Date: Mon, 2 Jun 2014 15:06:17 +0100 X-Google-Sender-Auth: V7DgVLrnejwnZGfdeMYhIV_29Go Message-ID: From: George Dunlap To: Jan Beulich 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-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 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? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel