Re: Design session "grant v3"

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.09.2022 09:04, Juergen Gross wrote:
> On 26.09.22 08:57, Jan Beulich wrote:
>> 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.
> 
> In case the data page can't be used for anything else, what would be the
> point of revoking the grant? The page would leak in both cases (revoking
> or not).

Sure, but don't you agree it would be better for the guest to have a way
to cleanly shut down in case it notices a misbehaving backend, rather
than having its data corrupted in the process? Of course a guest won't
be able to tell malicious from buggy, but what to do in such a case
ought to be a guest policy, not behavior forced upon it from the outside.
Then again I guess "pass scratch page per revoke call" is meant to cover
that already, i.e. leaving it to the guest how to actually deal with a
failed revoke.

>>>>> 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?
> 
> Of course that would be possible, but using the feature would be limited
> to backends having been modified to test that new flag. In the end both
> sides would need to negotiate the feature usability.

Isn't it to be expected that this might need negotiating? Strictly speaking
it might not need to be: The backend's map request (for a sufficiently
large number of grants all in one go) could be checked for being all
contiguous in the applicably address spaces. That wouldn't require the
frontend to advertise anything. But an unaware frontend wouldn't be very
likely to produce suitable I/O requests in the first place, I suspect.

Jan