On 23.09.2022 11:31, Juergen Gross wrote:
> On 22.09.22 20:43, Jan Beulich wrote:
>> On 22.09.2022 15:42, Marek Marczykowski-Górecki wrote:
>>> Yann: can backend refuse revoking?
>>> Jürgen: it shouldn't be this way, but revoke could be controlled by feature
>>> flag; revoke could pass scratch page per revoke call (more flexible control)
>>
>> A single scratch page comes with the risk of data corruption, as all
>> I/O would be directed there. A sink page (for memory writes) would
>> likely be okay, but device writes (memory reads) can't be done from
>> a surrogate page.
>
> I don't see that problem.
>
> In case the grant is revoked due to a malicious/buggy backend, you can't
> trust the I/O data anyway.
I agree for the malicious case, but I'm less certain when is come to
buggy backends. Some bugs (like not unmapping a grant) aren't putting
the data at risk.
>>> Jürgen: we should consider interface to mapping large pages ("map this area
>>> as a large page if backend shared it as large page")
>>
>> s/backend/frontend/ I guess?
>
> Yes.
>
> But large pages have another downside: The backend needs to know it is a large
> page, otherwise it might get confused. So while this sounds like a nice idea,
> it
> is cumbersome in practice. But maybe someone is coming up with a nice idea how
> to solve that.
Couldn't that simply be a new GTF_superpage flag, with the size
encoded along the lines of AMD IOMMUs encode superpages (setting all
but the top-most of the bits not used for the actual frame address)
in the address part of the entry?
Jan
