[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 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?

 -George

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.