Mark Burton writes:
> We will roll a patch for this approach shortly.
> For the ‘better’ approach - I think it’s something we will consider doing….
> but as you say, one thing at a time.
> I dont think it will be too bad to implement, given what already exists in the
> tlb’s - (except if we have
On 15 December 2014 at 13:16, Paolo Bonzini wrote:
> If not, it should not need any change to the memory API; you can do it
> entirely within cputlb.c, roughly the same as the handling of
> TLB_NOTDIRTY. It also marks pages as I/O, but only internally within TCG.
Speaking of TLB_NOTDIRTY, I just
On 15/12/2014 14:39, Peter Maydell wrote:
>> >
>> > How would "add a mutex" work unless you add a mutex or CAS to each and
>> > every qemu_st operation?
> Same way our current approach works -- we simply don't implement
> "stores interrupt ll/sc operations": only a store-conditional
> can break a
> On 15 Dec 2014, at 14:39, Peter Maydell wrote:
>
> [I'm getting bounces from mt...@greensocs.com so have taken
> them off cc:
> 550 5.1.1 : Recipient address rejected: User
> unknown in virtual mailbox table]
>
the address should be: mt...@listserver.greensocs.com
Not sure who introduced the
[I'm getting bounces from mt...@greensocs.com so have taken
them off cc:
550 5.1.1 : Recipient address rejected: User
unknown in virtual mailbox table]
On 15 December 2014 at 13:32, Paolo Bonzini wrote:
>
>
> On 15/12/2014 14:28, Peter Maydell wrote:
>> Personally I would start out with this appr
(not address of mttcg list server)
> On 15 Dec 2014, at 14:32, Paolo Bonzini wrote:
>
>
>
> On 15/12/2014 14:28, Peter Maydell wrote:
>> Personally I would start out with this approach. We're going to
>> need a "do this whole sequence atomically wrt other guest CPUs"
>> mechanism anyway, so it
On 15 December 2014 at 13:28, Paolo Bonzini wrote:
>
>
> On 15/12/2014 14:23, Peter Maydell wrote:
>> > What are the intended semantics for reads/writes from the outside world?
>> > Should they cause the ll/sc pair to retry or not?
>> Assuming that by "outside world" you mean "some other CPU in t
We will roll a patch for this approach shortly.
For the ‘better’ approach - I think it’s something we will consider doing…. but
as you say, one thing at a time.
I dont think it will be too bad to implement, given what already exists in the
tlb’s - (except if we have to protect (for some architect
On 15/12/2014 14:28, Peter Maydell wrote:
> Personally I would start out with this approach. We're going to
> need a "do this whole sequence atomically wrt other guest CPUs"
> mechanism anyway, so it's not implementing something we wouldn't
> otherwise need. And it's the simple thing to do. It's
On 15 December 2014 at 12:56, Mark Burton wrote:
> One proposal is ‘simply’ to add a mutex around this code, such
> that multi-threaded TCG will correctly update/read these saved
> address/values.
> This _should_ maintain the status-quo. Things that were broken
> before will remain broken, nothing
On 15/12/2014 14:23, Peter Maydell wrote:
> > What are the intended semantics for reads/writes from the outside world?
> > Should they cause the ll/sc pair to retry or not?
> Assuming that by "outside world" you mean "some other CPU in this
> cluster" [in ARM-speak, some other observer in the sa
On 15 December 2014 at 13:16, Paolo Bonzini wrote:
> On 15/12/2014 13:56, Mark Burton wrote:
>> A third proposal is to mark pages as IO when a ld/st ex is performed to
>> them. Then to augment the memory API to indicate that a ld/st ex is in
>> hand, allowing the memory chain to decide if it shoul
On 15/12/2014 13:56, Mark Burton wrote:
> A third proposal is to mark pages as IO when a ld/st ex is performed to
> them. Then to augment the memory API to indicate that a ld/st ex is in
> hand, allowing the memory chain to decide if it should allow the write
> or cause a fault. This would seem t
Comments please….
Choices for Atomic instructions:
The current approach (for ARM at least) for Ld and St exclusive inside Qemu
simply records the address and the value that atomic read instructions attempt
to read from. When an atomic write happens, it checks the value and address
remain the sa
14 matches
Mail list logo
