All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH] target/ppc/spapr: Update H_GET_CPU_CHARACTERISTICS bits
Date: Tue, 04 May 2021 18:50:54 +1000	[thread overview]
Message-ID: <1620117371.82b83ry366.astroid@bobo.none> (raw)
In-Reply-To: <YJCYKBF2YgEl8AEA@yekko>

Excerpts from David Gibson's message of May 4, 2021 10:41 am:
> On Mon, May 03, 2021 at 10:58:33PM +1000, Nicholas Piggin wrote:
>> There are several new bits added to the hcall which reflect new issues
>> found and new hardware mitigations.
>> 
>> This adds the link stack flush behaviour, link stack flush accelerated
>> instruction capability, and several L1D flush type behaviours (which are
>> now being specified as negative in order to simplify patched kernel
>> compatibility with older firmware).
> 
> So, to clarify here, the bits your adding aren't advertising any new
> behaviour on qemu/KVM's part, they're just new ways of advertising the
> same behaviour?

I... think so. "Behaviour" is in context of the hcall that advertises
how the processor behaves (or what the guest must do for security).

The new NO_ bits added are for processors that don't require a particular
flush. The FLUSH_LINK_STACK was basically always required but I think
Linux just keyed off the count cache flush and did both at once.

The new LINK_FLUSH_ASSIST is a new processor feature the guest will use
to implement link stack flushing, so maybe that does need a cap?

> 
>> 
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>>  hw/ppc/spapr_hcall.c   | 5 +++++
>>  include/hw/ppc/spapr.h | 6 ++++++
>>  2 files changed, 11 insertions(+)
>> 
>> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
>> index 7275d0bba1..f656620232 100644
>> --- a/hw/ppc/spapr_hcall.c
>> +++ b/hw/ppc/spapr_hcall.c
>> @@ -1878,6 +1878,9 @@ static target_ulong h_get_cpu_characteristics(PowerPCCPU *cpu,
>>          behaviour |= H_CPU_BEHAV_L1D_FLUSH_PR;
>>          break;
>>      case SPAPR_CAP_FIXED:
>> +        behaviour |= H_CPU_BEHAV_NO_L1D_FLUSH_ENTRY;
>> +        behaviour |= H_CPU_BEHAV_NO_L1D_FLUSH_UACCESS;
>> +        behaviour |= H_CPU_BEHAV_NO_STF_BARRIER;
>>          break;
>>      default: /* broken */
>>          assert(safe_cache == SPAPR_CAP_BROKEN);
>> @@ -1909,9 +1912,11 @@ static target_ulong h_get_cpu_characteristics(PowerPCCPU *cpu,
>>          break;
>>      case SPAPR_CAP_WORKAROUND:
>>          behaviour |= H_CPU_BEHAV_FLUSH_COUNT_CACHE;
>> +        behaviour |= H_CPU_BEHAV_FLUSH_LINK_STACK;
>>          if (count_cache_flush_assist) {
>>              characteristics |= H_CPU_CHAR_BCCTR_FLUSH_ASSIST;
>>          }
>> +        /* Should have a way to enable BCCTR_LINK_FLUSH_ASSIST */
> 
> Do we need a new spapr capability for this link flush thing?

It is independent of the FLUSH_COUNT_CACHE capability, so it seems like
it should I think? Should that be added as a following patch?

Thanks,
Nick


  reply	other threads:[~2021-05-04  8:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-03 12:58 [PATCH] target/ppc/spapr: Update H_GET_CPU_CHARACTERISTICS bits Nicholas Piggin
2021-05-04  0:41 ` David Gibson
2021-05-04  8:50   ` Nicholas Piggin [this message]
2021-05-05  4:20     ` David Gibson
2021-06-15  4:40       ` Nicholas Piggin

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=1620117371.82b83ry366.astroid@bobo.none \
    --to=npiggin@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.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.