[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] target/alpha: Take BQL around clock manipulatio

From: Alex Bennée
Subject: Re: [Qemu-devel] [PATCH] target/alpha: Take BQL around clock manipulations
Date: Tue, 07 Mar 2017 06:55:07 +0000
User-agent: mu4e 0.9.19; emacs 25.2.8

Richard Henderson <address@hidden> writes:

> On 03/07/2017 08:00 AM, Paolo Bonzini wrote:
>>> Signed-off-by: Richard Henderson <address@hidden>
>>> ---
>>> This is similar to the patch that I saw go by for MIPS.
>>> I hadn't noticed any problems caused by this lack of locking.  This may
>>> be because interrupts cannot be delivered while in PALmode while these
>>> registers are being manipulated.  However, it's always better to obey
>>> the rules, right?
>> This should not be necessary, clocks and timers are thread-safe.  Time
>> to make a list of the few things that are, I guess.
>> There are issues if data is accessed by device models and CPU out of
>> the lock, but everything seems fine for typhoon_alarm_timer.
> This isn't typhoon_alarm_timer, but the move-to-special-register
> instruction on the cpu side.
> But I guess I misunderstood the problem that was happening for MIPS.
> If nothing needs changing for Alpha, that's great.

Fundamentally the MIPS instructions ended up calling into hw/mips/ which
could then end up triggering an IRQ (at which point the BQL assertion
kicks in).

Basically crossing from target/foo/helper to hw/foo/emulation is the
warning sign that you need to ensure you have appropriate device
emulation locking going on.

Helpers just messing with their own env should be able to continue just

> r~

Alex Bennée

reply via email to

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