From: Jan Beulich <jbeulich@suse.com>
To: Wei Liu <wl@xen.org>
Cc: "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
"Grall, Julien" <jgrall@amazon.com>,
"roger.pau@citrix.com" <roger.pau@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
"Xia, Hongyan" <hongyxia@amazon.com>
Subject: Re: [Xen-devel] [PATCH v2] x86/domain_page: implement pure per-vCPU mapping infrastructure
Date: Fri, 21 Feb 2020 15:55:28 +0100 [thread overview]
Message-ID: <7c4d3a86-091d-c3db-8bfd-1b2a14b1639f@suse.com> (raw)
In-Reply-To: <20200221143608.jexjistjxuijqkme@debian>
On 21.02.2020 15:36, Wei Liu wrote:
> On Fri, Feb 21, 2020 at 02:31:08PM +0100, Jan Beulich wrote:
>> On 21.02.2020 13:52, Xia, Hongyan wrote:
>>> On Fri, 2020-02-21 at 11:50 +0000, Wei Liu wrote:
>>>> On Thu, Feb 06, 2020 at 06:58:23PM +0000, Hongyan Xia wrote:
>>>>> + if ( hashmfn != mfn && !vcache->refcnt[idx] )
>>>>> + __clear_bit(idx, vcache->inuse);
>>>>
>>>> Also, please flush the linear address here and the other __clear_bit
>>>> location.
>>>
>>> I flush when a new entry is taking a slot. Yeah, it's probably better
>>> to flush earlier whenever a slot is no longer in use.
>>
>> Question is whether such individual flushes aren't actually
>> more overhead than a single flush covering all previously
>> torn down entries, done at suitable points (see the present
>> implementation).
>
> I asked to flush because I was paranoid about leaving stale entry after
> the slot is reclaimed. I think the address will be flushed when a new
> entry is inserted.
>
> So the question would be whether we care about leaving a stale entry in
> place until a new one is inserted.
Well, we apparently don't have an issue with such today, so
unless explicitly stated to the contrary I think any replacement
implementation can and should make the same assumptions /
guarantees.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2020-02-21 14:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 18:58 [Xen-devel] [PATCH v2] x86/domain_page: implement pure per-vCPU mapping infrastructure Hongyan Xia
2020-02-21 11:50 ` Wei Liu
2020-02-21 12:52 ` Xia, Hongyan
2020-02-21 13:02 ` Andrew Cooper
2020-02-21 14:40 ` Xia, Hongyan
2020-02-21 13:31 ` Jan Beulich
2020-02-21 14:36 ` Wei Liu
2020-02-21 14:55 ` Jan Beulich [this message]
2020-02-21 14:58 ` Wei Liu
2020-02-21 15:08 ` Jan Beulich
2020-02-21 14:52 ` Xia, Hongyan
2020-02-21 14:59 ` Jan Beulich
2020-02-21 14:39 ` Wei Liu
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=7c4d3a86-091d-c3db-8bfd-1b2a14b1639f@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=hongyxia@amazon.com \
--cc=jgrall@amazon.com \
--cc=roger.pau@citrix.com \
--cc=wl@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).