Re: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram

[Tim Deegan <tim@xxxxxxx>]

At 15:55 +0000 on 13 Feb (1392303343), Jan Beulich wrote:
> >>> On 13.02.14 at 16:46, George Dunlap <george.dunlap@xxxxxxxxxxxxx> 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.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel