On 10/7/22 09:50, Peter Maydell wrote:
On Fri, 7 Oct 2022 at 17:45, Richard Henderson
wrote:
On 10/7/22 06:47, Peter Maydell wrote:
Are there definitely no code paths where we might try to do
a page table walk with the iothread already locked ?
I'll double-check, but another possibility is
On Fri, 7 Oct 2022 at 17:45, Richard Henderson
wrote:
>
> On 10/7/22 06:47, Peter Maydell wrote:
> > Are there definitely no code paths where we might try to do
> > a page table walk with the iothread already locked ?
>
> I'll double-check, but another possibility is to simply perform the atomic
On 10/7/22 06:47, Peter Maydell wrote:
On Sat, 1 Oct 2022 at 18:04, Richard Henderson
wrote:
Perform the atomic update for hardware management of the access flag
and the dirty bit.
A limitation of the implementation so far is that the page table
itself must already be writable, i.e. the dirty
On Fri, 7 Oct 2022 at 14:47, Peter Maydell wrote:
> Do we really need to go all the way back to restart_atomic_update?
> Are we allowed to do the access and dirty bit updates with separate
> atomic accesses?
I've just discovered that the latest revision of the Arm ARM (rev I.a)
is clearer on thi
On Sat, 1 Oct 2022 at 18:04, Richard Henderson
wrote:
>
> Perform the atomic update for hardware management of the access flag
> and the dirty bit.
>
> A limitation of the implementation so far is that the page table
> itself must already be writable, i.e. the dirty bit for the stage2
> page table
Perform the atomic update for hardware management of the access flag
and the dirty bit.
A limitation of the implementation so far is that the page table
itself must already be writable, i.e. the dirty bit for the stage2
page table must already be set, i.e. we cannot set both dirty bits
at the same
