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

> I cannot understand why we need to 
> restrict the CPU access to VRAM region but allow accessing from device.

We'd love to also do this for device accesses, but to date IOMMU
fault are unrecoverable, and hence this is not an option.

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

Why's that? I.e. why should a guest with emulated graphics not be
able to program a passed through device to access the VRAM directly?

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

I.e. without EPT no superpages. Afaict there's no such limitation on
the AMD side.

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

You didn't in any way negate the condition of superpage support to
be added post-4.4 in order for your other change to go in: Neither
http://lists.xenproject.org/archives/html/xen-devel/2014-02/msg01230.html
nor
http://lists.xenproject.org/archives/html/xen-devel/2014-02/msg01236.html
have been responded to by you. By not doing so, to me at least you
implicitly accepted the condition. And by now refusing to meet it, you
basically tell us that we shouldn't be doing compromises like this with
you in the future.

Jan


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