Re: Design session "grant v3"

[Juergen Gross <jgross@xxxxxxxx>]

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

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


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature