[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Design session "grant v3"


  • To: Juergen Gross <jgross@xxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 26 Sep 2022 08:57:51 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zYf2tP+ZpnmF19YH10EKsbxLjZfVuIssD9txRvQgDGM=; b=LWE3CVzyxikx9iexD6moF8DuZyH5HMRkA5i2VB1IJHUI4pTbo7qknFLZG/M54HWXIWDCbQr8xNRT+nOZp4mwuL3Is+m/ylYQVzPgbak7QWpvUGAXnvUYPfo9puqooBTm/dr0Uanpqfus1ER2L1lSmori4bY9mMJW4iTC3UlPOGEpw5Ue8LdXOjN7ywyHQaBtX55SizGrZ+KLX0wAslvyHCHRu7gEA/i2s+TQZN1m3mO4ucGgDJE3TkYe5R7FiNTca+GRgXjuaph3J6Fx3MoRnvmDcX3yW6hme2vKDDRkVs8rUgo8lXQMLetUYlzGoHEbJi5mG2o+4V5E7fytjEEiUQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G8fmdhMt2L0YZw6zGSbUjkQRww9mRPljTjg1KkVWtczugbI3+Hl5yW3apeFJsMR+rA8juzvoHd/JVR5kZ9wrdEkvxDwFW2ZnQzH/8P66ZBDdlWNXWWh3wJYsLGHmk07DgeVYnQD9wBVNE9huEOgyDa2mQ/s1dIkqfvb2f7mcyn/relsXhaO+zzuejzm+S5mKQxufuSHW8VmKTfJ59pZq2+USFXLg/XU/udI0Hdpz1X1nYXVqP0Z5mCaYENsT1vVD0ezCo0gTsIivAPJTcutMgpeaP7ZXTB/c5eYI2aeROROQT3WI158zXaQmWFX7bOPLLh4H02mno2BlMmclNCdkjQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 26 Sep 2022 06:57:58 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.