qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-s390x] [Qemu-devel] [PATCH v1 14/33] s390x/tcg: Implement VECT


From: David Hildenbrand
Subject: Re: [qemu-s390x] [Qemu-devel] [PATCH v1 14/33] s390x/tcg: Implement VECTOR LOAD MULTIPLE
Date: Thu, 28 Feb 2019 20:05:42 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 28.02.19 18:15, Richard Henderson wrote:
> On 2/28/19 12:36 AM, David Hildenbrand wrote:
>> On 27.02.19 17:02, Richard Henderson wrote:
>>> On 2/26/19 3:38 AM, David Hildenbrand wrote:
>>>> Also fairly easy to implement. One issue we have is that exceptions will
>>>> result in some vectors already being modified. At least handle it
>>>> consistently per vector by using a temporary vector. Good enough for
>>>> now, add a FIXME.
>>>>
>>>> Signed-off-by: David Hildenbrand <address@hidden>
>>>> ---
>>>>  target/s390x/insn-data.def      |  2 ++
>>>>  target/s390x/translate_vx.inc.c | 26 ++++++++++++++++++++++++++
>>>>  2 files changed, 28 insertions(+)
>>>
>>> I suppose the fixme is good enough.  For the record, I think you could do 
>>> the
>>> check with just two loads -- the first and last quadword.  After that, none 
>>> of
>>> the other loads can fault, and you can store everything else into the
>>> destination vectors as you read them.
>>
>> Aren't such approaches prone to races if other VCPUs invalidate page
>> tables/TLB entries?
> 
> No, because...
> 
>> (or am I messing up things and the MMU of this VCPU won't be touched
>> while in this block and once we touched all applicable pages, it cannot
>> fail anymore?)
> 
> Correct.
> 
> If vcpu 1 does a global invalidate, the time at which vcpu 2 acknowledges that
> invalidate is somewhat fluid.  VCPU 2 will see an interrupt, exit at a TB
> boundary, and then acknowledge.
> 
> VCPU 1 has to wait for the ack before it knows the operation is complete.
> 
> Thus no race within any given instruction's execution.

Okay, rings a bell, thanks! :)

So for writing from helpers, I can use probe_write(). What about testing
write access from TCG code?

I could do a load, followed by a store of the loaded value. This should
work in most cases (but eventually could be observed by somebody really
wanting to observe it - which is highly unlikely).


-- 

Thanks,

David / dhildenb



reply via email to

[Prev in Thread] Current Thread [Next in Thread]