From: George Dunlap <George.Dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
Paul Durrant <Paul.Durrant@citrix.com>,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Ping: [PATCH v3 0/4] x86/HVM: implement memory read caching
Date: Thu, 11 Oct 2018 16:33:07 +0000 [thread overview]
Message-ID: <F05D0D1B-0119-47A4-8643-5E6411F1233B@citrix.com> (raw)
In-Reply-To: <5BBF772802000078001F0CAD@prv1-mh.provo.novell.com>
> On Oct 11, 2018, at 5:15 PM, Jan Beulich <JBeulich@suse.com> wrote:
>
>>>> On 11.10.18 at 17:54, <George.Dunlap@citrix.com> wrote:
>
>>> On Oct 2, 2018, at 1:47 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>
>>>>>> On 02.10.18 at 12:51, <andrew.cooper3@citrix.com> wrote:
>>>
>>>> This doesn't behave like real hardware, and definitely doesn't behave as
>>>> named - "struct hvmemul_cache" is simply false. If it were named
>>>> hvmemul_psc (or some other variation on Paging Structure Cache) then it
>>>> wouldn't be so bad, as the individual levels do make more sense in that
>>>> context
>>>
>>> As previously pointed out (without any suggestion coming back from
>>> you), I chose the name "cache" for the lack of a better term. However,
>>> I certainly disagree with naming it PSC or some such, as its level zero
>>> is intentionally there to be eventually used for non-paging-structure
>>> data.
>>
>> I can think of lots of descriptive names which could yield unique
>> three-letter acronyms:
>>
>> Logical Read Sequence
>> Logical Read Series
>> Logical Read Record
>> Read Consistency Structure
>> Consistent Read Structure
>> Consistent Read Record
>> Emulation Read Record
>> […]
>
> Well, I'm not sure LRS, LRR, RCS, CRS, CRR, or ERR would be
> easily recognizable as what they stand for. To be honest I'd
> prefer a non-acronym. Did you see my consideration towards
> "latch”?
Of course not; that’s why you put the long form name in a comment near the declaration. :-)
I don’t think I’ve personally used “latch” with that meaning very frequently (at least not in the last 10 years), so to me it sounds a bit obscure. I would probably go with something else myself but I don’t object to it.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-10-11 16:33 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-11 13:10 [PATCH v2 0/4] x86/HVM: implement memory read caching Jan Beulich
2018-09-11 13:13 ` [PATCH v2 1/4] x86/mm: add optional cache to GLA->GFN translation Jan Beulich
2018-09-11 13:40 ` Razvan Cojocaru
2018-09-19 15:09 ` Wei Liu
2018-09-11 13:14 ` [PATCH v2 2/4] x86/mm: use optional cache in guest_walk_tables() Jan Beulich
2018-09-11 16:17 ` Paul Durrant
2018-09-12 8:30 ` Jan Beulich
2018-09-19 15:50 ` Wei Liu
2018-09-11 13:15 ` [PATCH v2 3/4] x86/HVM: implement memory read caching Jan Beulich
2018-09-11 16:20 ` Paul Durrant
2018-09-12 8:38 ` Jan Beulich
2018-09-12 8:49 ` Paul Durrant
2018-09-19 15:57 ` Wei Liu
2018-09-20 6:39 ` Jan Beulich
2018-09-20 15:42 ` Wei Liu
2018-09-11 13:16 ` [PATCH v2 4/4] x86/HVM: prefill cache with PDPTEs when possible Jan Beulich
2018-09-13 6:30 ` Tian, Kevin
2018-09-13 8:55 ` Jan Beulich
2018-09-14 2:18 ` Tian, Kevin
2018-09-14 8:12 ` Jan Beulich
2018-09-25 14:14 ` [PATCH v3 0/4] x86/HVM: implement memory read caching Jan Beulich
2018-09-25 14:23 ` [PATCH v3 1/4] x86/mm: add optional cache to GLA->GFN translation Jan Beulich
2018-09-25 14:24 ` [PATCH v3 2/4] x86/mm: use optional cache in guest_walk_tables() Jan Beulich
2018-09-25 14:25 ` [PATCH v3 3/4] x86/HVM: implement memory read caching Jan Beulich
2018-09-26 11:05 ` Wei Liu
2018-10-02 10:39 ` Ping: " Jan Beulich
2018-10-02 13:53 ` Boris Ostrovsky
2018-10-09 5:19 ` Tian, Kevin
2018-09-25 14:26 ` [PATCH v3 4/4] x86/HVM: prefill cache with PDPTEs when possible Jan Beulich
2018-09-25 14:38 ` Paul Durrant
2018-10-02 10:36 ` Ping: [PATCH v3 0/4] x86/HVM: implement memory read caching Jan Beulich
2018-10-02 10:51 ` Andrew Cooper
2018-10-02 12:47 ` Jan Beulich
2018-10-11 15:54 ` George Dunlap
2018-10-11 16:15 ` Jan Beulich
2018-10-11 16:33 ` George Dunlap [this message]
2018-10-12 6:32 ` Jan Beulich
2018-10-11 6:51 ` Jan Beulich
2018-10-11 17:36 ` George Dunlap
2018-10-12 13:55 ` [PATCH v2 " Andrew Cooper
2018-10-12 14:19 ` Jan Beulich
2018-10-18 15:20 ` George Dunlap
2019-05-07 16:22 ` George Dunlap
2019-05-07 16:22 ` [Xen-devel] " George Dunlap
2019-05-07 16:26 ` Jan Beulich
2019-05-07 16:26 ` [Xen-devel] " Jan Beulich
2018-11-09 10:17 ` Jan Beulich
2019-02-14 15:14 ` Jan Beulich
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=F05D0D1B-0119-47A4-8643-5E6411F1233B@citrix.com \
--to=george.dunlap@citrix.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=Paul.Durrant@citrix.com \
--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.