[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC 1/3] accel/tcg: allow to invalidate a write
From: |
Richard Henderson |
Subject: |
Re: [Qemu-devel] [PATCH RFC 1/3] accel/tcg: allow to invalidate a write TLB entry immediately |
Date: |
Mon, 16 Oct 2017 11:06:49 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
On 10/16/2017 12:24 AM, David Hildenbrand wrote:
> 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?
Let's just go ahead with TLB_INVALID_MASK; we'll revisit if it gets to be
confusing.
r~