From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] Don't track all memory when enabling log dirty to track vram Date: Thu, 13 Feb 2014 16:25:52 +0000 Message-ID: <52FCF210.7090702@eu.citrix.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140213162022.GE82703@deinos.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan , Jan Beulich Cc: Yang Z Zhang , "andrew.cooper3@citrix.com" , xenbugs , Xiantao Zhang , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org title 38 Implement VT-d large pages so we can avoid sharing between EPT and IOMMU owner it Yang Z Zhang thanks On 02/13/2014 04:20 PM, Tim Deegan wrote: > At 15:55 +0000 on 13 Feb (1392303343), Jan Beulich wrote: >>>>> On 13.02.14 at 16:46, George Dunlap wrote: >>> On 02/12/2014 12:53 AM, Zhang, Yang Z wrote: >>>> George Dunlap wrote on 2014-02-11: >>>>> 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. >> That would be Tim then, as he would have to approve of it anyway. > Done. > >> I should also say that while I certainly understand the argumentation >> above, I would still want to go this route only with the promise that >> B is going to be worked on reasonably soon after the release, ideally >> with the goal of backporting the changes for 4.4.1. > Agreed. OK -- I've retitled the bug and am going to leave it open. -George