xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: "Brian Woods" <brian.woods@amd.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/5] x86/AMD: make C-state handling independent of Dom0
Date: Fri, 21 Jun 2019 08:56:22 -0600	[thread overview]
Message-ID: <5D0CF016020000780023A30D@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <20190621142925.GA19049@amd.com>

>>> On 21.06.19 at 16:29, <Brian.Woods@amd.com> wrote:
> On Fri, Jun 21, 2019 at 12:37:47AM -0600, Jan Beulich wrote:
>> >>> On 19.06.19 at 17:54, <Brian.Woods@amd.com> wrote:
>> > On Wed, Jun 19, 2019 at 12:20:40AM -0600, Jan Beulich wrote:
>> >> >>> On 18.06.19 at 19:22, <Brian.Woods@amd.com> wrote:
>> >> > On Tue, Jun 11, 2019 at 06:42:33AM -0600, Jan Beulich wrote:
>> >> >> >>> On 10.06.19 at 18:28, <andrew.cooper3@citrix.com> wrote:
>> >> >> > On 23/05/2019 13:18, Jan Beulich wrote:
>> >> >> >> TBD: We may want to verify that HLT indeed is configured to enter CC6.
>> >> >> > 
>> >> >> > I can't actually spot anything which talks about HLT directly.  The
>> >> >> > closest I can post is CFOH (cache flush on halt) which is an
>> >> >> > auto-transition from CC1 to CC6 after a specific timeout, but the
>> >> >> > wording suggests that mwait would also take this path.
>> >> >> 
>> >> >> Well, I had come across a section describing how HLT can be
>> >> >> configured to be the same action as the I/O port read from one
>> >> >> of the three ports involved in C-state management
>> >> >> (CStateBaseAddr+0...2). But I can't seem to find this again.
>> >> >> 
>> >> >> As to MWAIT behaving the same, I don't think I can spot proof
>> >> >> of your interpretation or proof of Brian's.
>> >> > 
>> >> > It's not really documented clearly.  I got my information from the HW
>> >> > engineers.  I've already posted what information I know so I won't
>> >> > repeat it.
>> >> 
>> >> At least a pointer to where you had stated this would have been
>> >> nice. Iirc there's no promotion into CC6 in that case, in contrast
>> >> to Andrew's reading of the doc.
>> > 
>> > &mwait_v1_patchset
>> 
>> Hmm, I've looked through the patch descriptions there again, but I
>> can't find any explicit statement to the effect of there being no
>> promotion into deeper states when using MWAIT.
> 
> https://lists.xenproject.org/archives/html/xen-devel/2019-02/msg02007.html 

Thanks. Yes, it may be implied from there, but to me it's still not
explicit. Also recall that it was Andrew originally asking if any
promotion from CC1 is possible. I'm fine with you telling me it's
not, but Andrew may still want you pointing him at where this
is written down.

> Since you're under NDA, I can send you the email I received from the HW
> engineering but as a basic recap:
> 
> If the HW is configured to use CC6 for HLT (CC6 is enabled and some
> other NDA bits which gets OR'd with firmware so you can only
> functionally CC6 on HLT off, but can't make sure it's on), then the
> flow is:
> 1) HLT
> 2) timer
> 3) flush the caches etc
> 4) CC6
> 
> This can be interrupted though.  The HW engineer said that while they
> aren't the same (as IO based C-states), they end up at the same place.
> 
> The whole reason HLT was selected to be used in my patches is because
> we can't look in the CST table from Xen and it's always safe to use,
> even if CC6 is disabled in BIOS (which we can't tell).  At this point,
> I'm repeating our conversion we had in my v1 patch set.  If you need
> any further info, let me know.

Thanks, I recall all of this. I don't see though how it's related to the
question of whether the CPU would really remain in C1 when using
MWAIT (i.e. going back to Andrew's original finding of promotion from
CC1 to CC6). Now I do realize that C1 != CC1, but this doesn't help
clarifying things in any way.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-06-21 14:56 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23 12:06 [PATCH 0/5] x86: CPU idle management adjustments Jan Beulich
2019-05-23 12:06 ` [Xen-devel] " Jan Beulich
2019-05-23 12:16 ` [PATCH 1/5] x86/cpuidle: switch to uniform meaning of "max_cstate=" Jan Beulich
2019-05-23 12:16   ` [Xen-devel] " Jan Beulich
2019-06-10 15:48   ` Andrew Cooper
2019-06-11 12:13     ` Jan Beulich
2019-05-23 12:17 ` [PATCH 2/5] x86/cpuidle: really use C1 for "urgent" CPUs Jan Beulich
2019-05-23 12:17   ` [Xen-devel] " Jan Beulich
2019-06-10 15:50   ` Andrew Cooper
2019-05-23 12:18 ` [PATCH 3/5] x86/AMD: make C-state handling independent of Dom0 Jan Beulich
2019-05-23 12:18   ` [Xen-devel] " Jan Beulich
2019-06-10 16:28   ` Andrew Cooper
2019-06-11 12:42     ` Jan Beulich
2019-06-18 17:22       ` Woods, Brian
2019-06-19  6:20         ` Jan Beulich
2019-06-19 15:54           ` Woods, Brian
2019-06-21  6:37             ` Jan Beulich
2019-06-21 14:29               ` Woods, Brian
2019-06-21 14:56                 ` Jan Beulich [this message]
2019-06-21 15:26                   ` Woods, Brian
2019-05-23 12:18 ` [PATCH 4/5] x86: allow limiting the max C-state sub-state Jan Beulich
2019-05-23 12:18   ` [Xen-devel] " Jan Beulich
2019-06-10 16:43   ` Andrew Cooper
2019-06-11 12:46     ` Jan Beulich
2019-05-23 12:19 ` [PATCH 5/5] tools/libxc: allow controlling " Jan Beulich
2019-05-23 12:19   ` [Xen-devel] " Jan Beulich
2019-05-24 14:00   ` Wei Liu
2019-05-24 14:00     ` [Xen-devel] " Wei Liu
2019-06-10 16:54   ` Andrew Cooper
2019-06-11 12:50     ` 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=5D0CF016020000780023A30D@prv1-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=brian.woods@amd.com \
    --cc=roger.pau@citrix.com \
    --cc=wei.liu2@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 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).