All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: paul@xen.org
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: meaning and use of IOMMU_FLUSHF_added
Date: Thu, 19 Aug 2021 13:10:03 +0200	[thread overview]
Message-ID: <f89011ff-dd4c-aa60-ebcb-1baba5c431ed@suse.com> (raw)
In-Reply-To: <d426b1fc-cf57-469a-59c8-a2d28ed2e312@xen.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).

Jan



      reply	other threads:[~2021-08-19 11:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18 10:51 meaning and use of IOMMU_FLUSHF_added Jan Beulich
2021-08-18 12:09 ` Jan Beulich
2021-08-18 14:15   ` Paul Durrant
2021-08-19 11:10     ` Jan Beulich [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f89011ff-dd4c-aa60-ebcb-1baba5c431ed@suse.com \
    --to=jbeulich@suse.com \
    --cc=paul@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.