Re: [Xen-devel] [v6][PATCH 2/2] xen:vtd: missing RMRR mapping while share EPT

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Jan Beulich wrote on 2014-09-17:
>>>> On 17.09.14 at 04:42, <kevin.tian@xxxxxxxxx> wrote:
>>>> From: Chen, Tiejun
>>> Sent: Tuesday, September 16, 2014 6:01 PM On 2014/9/16 9:24, Chen,
>>> Tiejun wrote:
>>>> Jan,
>>>> 
>>>> What's your last judgement?
>>>> 
>>>> Could we apply these two separate patches in advance? I think
>>>> actually they aren't blocking the remains what we tried to do in
>>>> another RFC series, but now we really need them to make sure GFX
>>>> passthrough can work well.
>>>> 
>>>> For that RFC I have to take more time to cover all scenarios, so
>>>> as you saw its really a slow process I can push forward.
>>> 
>>> Any consideration?
>>> 
>> 
>> Given the facts that:
>> 
>> - earlier two patches can fix an important usage of GPU pass-through
>> for Windows VM
>> 
>> - earlier two patches don't make things worse
>> 
>> - current patch set still needs quite some effort for a robust RMRR
>> implementation
>> 
>> I'd suggest taking earlier two patches to catch 4.5 release, while
>> the big patch set is ongoing developed.
> 
> For the record: I'm intending to take another look, but as time permits.
> For now my position stands that I don't look forward to take just
> those two patches. This is based on the bad experience we had with the
> promise by Intel to work on implementing large page support for non-

Can you point out which promise Intel have gave? If you mean the VT-d large 
page, please look the whole story carefully that I never give any promise to 
re-enable VT-d large page for separate mode. All the promise is made by 
yourself and you think Intel accepted you promise because I didn't refuse it 
explicitly. 

Here is the background if someone wants to know the whole story: 

I send out the patch to fix a VT-d issue with VRAM and George lists four 
solutions to solve this issue:
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.)
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.
C. Do buffer scanning rather than dirty vram tracking (SLOW)
D. Don't allow both a virtual video card and pass-through

I prefer A is better and my patch chose A. Here is my original comment:
" 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).
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."

You didn't object my comment, and the patch was applied to Xen.

Later, you gave the comment:
"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."

You didn't explain why B is better than A, but want me to give a promise to 
choose B. I didn't do it and you think I was "implicity accepted it" because I 
didn't reject it explicitly. 

Even there is misunderstood between us at that time, but the later discussion 
has clarified that I'd like to do it if you can prove current implement is 
buggy or B is better. Unfortunately, you didn't prove it but now you are saying 
Intel doesn't keep its promise. You cannot give a strong reason to show B is 
better but how you can expect me to give a promise to implement B?

I really think you need to apology to all Intel developers for saying such 
irresponsible words to Intel over and over again.

> shared EPT/VT-d page tables in order to get a smaller scale fix
> accepted into 4.4. I'm not going to rely on promises of this kind
> again, and hence I'm willing to accept said patches only if they have
> no drawbacks (figuring this out is what I actually need some more time than 
> to just write an email).
> 
> Jan


Best regards,
Yang


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