[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
meaning and use of IOMMU_FLUSHF_added
- To: Paul Durrant <paul@xxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Wed, 18 Aug 2021 12:51:39 +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-SenderADCheck; bh=O6hzL3DNfA3lW70WyigyFIOgcuReGlZ8hd47kftdOY8=; b=RaOYCCmUPFsVXYnuJre9pGuqS3NCbQVdCFDT6rRBzUMYmn0XS2TtSsWHTBF3utlLT3s/p2BXz3fGGlWRVzqsmph2D+QEC7Ij4ntV1crXkTVzAN0rW9E+m8BmKyQKXBSvRuC17jkjU3NSAgNI172zqQyp8syzqBgVlaOX9TtCbRAm4d0uaglW3+va0h6VOihVYkQEhIiIpIZRLvNvPAx2JE7SEV3d+DkjaUbhJyWH5wmcpPado9qltG3uEoZhXghPK/dt5yQ3GKSdfTdkkp1M2enWm3xrtzGleaO9g3hXR1HW1rfmmtNynXh9SAkQXB3W9AUkU0ALoWU7AG0gUw/7DA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IFBJgUV539R/3z+vCpKlSmUJHj/BcSBojn33mHHdxEi1C4bL59oFIYOHDaeJhTJwY16TtGnFJu1xudaO3yrC9u4ng/TuOpzqnIOcvIj4E91HPReTVPwlaODFHwthW7+kMftwOd7hHmsDZ4/avwKBTf5wgqG4EYOXNRM5Go5i6QyWGY4n9ZQnJr/OpwJCikCAMuUkpdbbQtkAd0PZuG2m4AV6xjkoN10k/6tjE56VeFubsolWtT8pBKNpBoMRXI3uwCc2MPd8yr21LCheXtNeSVpgw8SQUq1lQkRXFXB73yca1JoNyGf/RG3D7LxF3icWX7FWs++iGxL62ufO8CZr5w==
- Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Wed, 18 Aug 2021 10:51:50 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
Paul,
back at the time I did already question your intended meaning of
this flag. I notice that there's presently no consumer of it being
set (apart from yielding non-zero flush_flags). I'm afraid this
model makes accumulation of flush flags not work properly: With
both flags set and more than a single page altered, it is
impossible to tell apart whether two present PTEs were altered, or
a non-present and a present one.
VT-d's flushing needs to know the distinction; it may in fact be
necessary to issue two flushes (or a single "heavier" one) when
both non-present and present entries got transitioned to present
in one go. Luckily no flush accumulation has been committed so
far (besides some during Dom0 construction), meaning this has only
been a latent issue until now that I try to get large page
mappings to work. (I think I have page table construction working,
but after the removal of some debug output I'm now facing faults
on non-present entries which I believe are actually present in the
page tables, albeit I yet have to check that.)
Question therefore is: Do we want to re-purpose the flag (my
preference), or do I need to add a 3rd one (in which case I'm
afraid I can't think of a good name, with "added" already in use)?
Jan
|
