All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Richard Henderson <richard.henderson@linaro.org>, qemu-devel@nongnu.org
Cc: thuth@redhat.com, cohuck@redhat.com,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] [PATCH RFC 1/3] accel/tcg: allow to invalidate a write TLB entry immediately
Date: Mon, 16 Oct 2017 09:24:47 +0200	[thread overview]
Message-ID: <a1f27655-5a3b-0e1f-cca3-12c09b7cbe51@redhat.com> (raw)
In-Reply-To: <30b6f3a1-bfeb-6172-5233-2f7d444399fc@linaro.org>

On 27.09.2017 19:48, Richard Henderson wrote:
> On 09/27/2017 10:00 AM, David Hildenbrand wrote:
>> Background: s390x implements Low-Address Protection (LAP). If LAP is
>> enabled, writing to effective addresses (before any transaltion)
>> 0-511 and 4096-4607 triggers a protection exception.
>>
>> So we have subpage protection on the first two pages of every address
>> space (where the lowcore - the CPU private data resides).
>>
>> By immediately invalidating the write entry but allowing the caller to
>> continue, we force every write access onto these first two pages into
>> the slow path. we will get a tlb fault with the specific accessed
>> addresses and can then evaluate if protection applies or not.
>>
>> We have to make sure to ignore the invalid bit if tlb_fill() succeeds.
> 
> This is similar to a scheme I proposed to PMM wrt handling ARM v8M translation.
>  Reusing TLB_INVALID_MASK would appear to work, but I wonder if it wouldn't be
> clearer to use another bit.  I believe I had proposed a TLB_FORCE_SLOW_MASK.
> 
> Thoughts, Peter?

As two weeks have passed:

Any further opinions? Richard, how do you want me to continue with this?

Thanks!

-- 

Thanks,

David

  parent reply	other threads:[~2017-10-16  7:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-27 17:00 [Qemu-devel] [PATCH RFC 0/3] s390x/tcg: LAP support using immediate TLB invalidation David Hildenbrand
2017-09-27 17:00 ` [Qemu-devel] [PATCH RFC 1/3] accel/tcg: allow to invalidate a write TLB entry immediately David Hildenbrand
2017-09-27 17:48   ` Richard Henderson
2017-09-27 18:50     ` David Hildenbrand
2017-10-16  7:24     ` David Hildenbrand [this message]
2017-10-16 18:06       ` Richard Henderson
2017-09-27 17:00 ` [Qemu-devel] [PATCH RFC 2/3] s390x/tcg: low-address protection support David Hildenbrand
2017-09-27 17:51   ` Richard Henderson
2017-09-28  4:50   ` Thomas Huth
2017-09-28 13:08     ` David Hildenbrand
2017-09-29 11:27       ` Cornelia Huck
2017-10-12  8:41         ` Thomas Huth
2017-10-16  7:20           ` David Hildenbrand
2017-09-27 17:00 ` [Qemu-devel] [PATCH RFC 3/3] s390x/tcg: make STFL store into the lowcore David Hildenbrand
2017-09-27 17:52   ` Richard Henderson
2017-09-27 18:46     ` David Hildenbrand
2017-09-28  4:23       ` Thomas Huth
2017-09-29 12:43   ` Cornelia Huck
2017-09-29 11:49 ` [Qemu-devel] [PATCH RFC 0/3] s390x/tcg: LAP support using immediate TLB invalidation Cornelia Huck
2017-09-29 12:09   ` David Hildenbrand
2017-09-29 12:13     ` Cornelia Huck

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=a1f27655-5a3b-0e1f-cca3-12c09b7cbe51@redhat.com \
    --to=david@redhat.com \
    --cc=agraf@suse.de \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thuth@redhat.com \
    /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.