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

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

Jan Beulich wrote on 2014-05-20:
>>>> On 20.05.14 at 12:12, <George.Dunlap@xxxxxxxxxxxxx> wrote:
>> On Tue, May 20, 2014 at 8:20 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>> On 20.05.14 at 05:13, <yang.z.zhang@xxxxxxxxx> wrote:
>>>> George Dunlap wrote on 2014-05-19:
>>>>> Avoiding these by "hoping" that the guest OS doesn't DMA into a
>>>>> video buffer isn't really robust enough.  I think that was Tim
>>>>> and Jan's
>>>> 
>>>> Video buffer is only one case. How we can prevent the DMA to other
>>>> reserved region?
>>> 
>>> You continue to neglect the difference: Accessing VRAM this way is
>>> legitimate (and potentially useful). And - as just said in the
>>> other reply - ideally we'd also simply ignore accesses to reserved

Can you give an example of what legitmate case you are mentioned twice(You 
mentioned it also in other reply)? I cannot understand why we need to restrict 
the CPU access to VRAM region but allow accessing from device. As I known, for 
gfx passthrough, both device and CPU are able to access them. And for emulated 
gfx, only software will access it which same as current we see in Xen.

>>> regions (and in fact we try to, by not immediately bringing down a
>>> guest device doing such).
>> 
>> On the other hand, just to play devil's advocate here: Implementing
>> separate IOMMU tables (including superpages) isn't free; it has a
>> non-negligible cost, both in initial developer time, continuing
>> maintenance (code complexity, fixing bugs), extra memory at
>> run-time, &c.
>> 
>> Of all the things we could invest that developer time doing, why
>> should we make it possible to DMA into VRAM, rather than doing
>> something else?
> 
> While I agree that the question is valid, my position really is that
> it was a mistake to implement the IOMMU code without superpage

We support the superpage via sharing EPT and VT-d pagetable.

> support, i.e. I view this as a shortcoming independent of the VRAM
> issue, and I would want to see this fixed rather sooner than later.
> Had it been done properly from the beginning (like one would expect
> for non-experimental code), a lot of this discussion could have been
> avoided, and we wouldn't have had to take the respective workaround
> close to the 4.4 release.

I still think the best solution is fixing the VRAM global log dirty mechanism 
which my previous patch already did. Because I cannot see any benefit with 
separating the page table.

> 
> Jan


Best regards,
Yang



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