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

Re: meaning and use of IOMMU_FLUSHF_added

  • To: paul@xxxxxxx
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 19 Aug 2021 13:10:03 +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=6w97TOntY/prn9DUSvtMN1qyrXG60d8REduGPNvHIbg=; b=kSg4TJMeyr9LIK+F2kyBZsXqHKcdKNkUC28b5BDtctli9mUSfFGDtH6zKfIY0j+ZePC/gxn1MIeEZwI17LC42xoBPOKkRwNK5KsHokoqgZPF1Q31rc0ETfLjRICES5RFoBBQXnVevFNCr4oFys+rsUIol5xxFNGBH5uoYecTUe3YIpWIUnfQ6jR8jH/WjgQl4Y0KPTpeCsf/ux/2Wx2VNNyCOYgnOdkHL8RV0cUJigjIMNxUeLY7q/CSVcHtOWucgwQ0S3LrInIBCnpaNCi6FTkl/YKKF7Y7iNLuzYfRegwLhOWpo6kk/MB2qcFisYgTTEzSwuAAjYlWIlWdvAoaHg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TcDW/pnYD9Uv7+pEFYLUTODSdZ28QtYhIHcwSfezjM6xPA2qaLqXcaDS4RlvV8j55X66UddYHaNhNQhKt24MXKKIStbZBqzPmK6yIvpoJj7FwCBTjXPq3SyzGnSmpqVDjPp5zENCApvkabDj8/0U0ObnY5ApblCDvH/U3RfUwz37w7w2C91I2+KFN4O3J+1vi7v9qLZ8Nkm60msO+d9/CCGYbAR1euEV/WB1gtKTqxRp/ZNbcS7wGCmenYqPWKJYaClVESOd02sM7pHYQ5GVJn7fYB5ToKsIWOlbFu063R1ewUF3eU/ER1Sb6GdTsexyDBQCJREg3doOWtMNcTskZQ==
  • 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: Thu, 19 Aug 2021 11:10:11 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 18.08.2021 16:15, Paul Durrant wrote:
> On 18/08/2021 13:09, Jan Beulich wrote:
>> On 18.08.2021 12:51, Jan Beulich wrote:
>>> 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.
>> No two (or "heavier") flush looks to be needed upon further reading.
>> I did derive this from our setting of "did" to zero in that case,
>> but that looks to be wrong in the first place - it's correct only
>> for context cache entry flushes. I'll make a(nother) patch ...
> Yes, the intention of the flag was simply to allow a 'lighter' flush in 
> the case there are no modified entries as part of the accumulation. If 
> it is impossible to tell the difference then I guess it's not useful.

Actually things can remain as they are, I think. The problem really
was the flushing bug (patch sent earlier today): If it was necessary
to flush previously present entries with their actual did but not-
present ones with did 0, the flushing logic would have had a need to
know. With that bug fixed (and hence with flushing only needing a
yes/no indicator), all is fine as is (in this regard).




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