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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.05.14 at 10:37, <yang.z.zhang@xxxxxxxxx> wrote:
> Jan Beulich wrote on 2014-05-21:
>>>>> On 21.05.14 at 03:02, <yang.z.zhang@xxxxxxxxx> wrote:
>>> 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)?
>> 
>> What's wrong with loading some graphics data right from an I/O device
>> (disk, network) into the frame buffer?
> 
> Yes, it is ok. But we are talking about the DMA access to a 'readonly' 
> buffer. It is totally a wrong usage model to me.

What read-only buffer are you referring to? From guest perspective,
nothing that gets marked read-only due to log-dirty handling really is
read-only. The fact that migration doesn't work due to this with an
assigned device can be excused by the handling of such an assigned
device not being implemented anyway. But the fact that behind the
scenes VRAM gets marked read-only should be (but isn't) entirely
transparent to the guest.

I'm not going to reply to the rest of your mail, both because I'm getting
the impression that we're moving in circles, and because I might become
impolite otherwise.

Jan


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