qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 08/36] ppc/xive: introduce a simplified XIVE


From: David Gibson
Subject: Re: [Qemu-devel] [PATCH v5 08/36] ppc/xive: introduce a simplified XIVE presenter
Date: Fri, 30 Nov 2018 12:09:20 +1100
User-agent: Mutt/1.10.1 (2018-07-13)

On Thu, Nov 29, 2018 at 06:51:53PM +0100, Cédric Le Goater wrote:
> On 11/29/18 4:39 AM, Benjamin Herrenschmidt wrote:
> > On Thu, 2018-11-29 at 11:47 +1100, David Gibson wrote:
> >>
> >> 1) read/write accessors which take a word number
> 
> ok for single word updates of the structures.
> 
> >> 2) A "get" accessor which copies the whole structure, 
> 
> ok
> 
> >> but "write"
> >> accessor which takes a word number.  The asymmetry is a bit ugly, but
> >> it's the non-atomic writeback of the whole structure which I'm most
> >> uncomfortable with.
> 
> And, how would you make the update of the whole structure in RAM look 
> "atomic" under QEMU ? 

So, the BQL means it actually is atomic now (at least for PAPR where
the guest doesn't have access to it), but I don't want to rely on that
always being the case - there are moves to put less stuff under the
BQL, and with KVM we might be mapping some of these things such that
real hardware can touch it.

But the real point is that we don't *need* it to be atomic.  Perhaps
the individual field updates need to be atomic, but not writes to the
END as a whole.  Writing back the whole thing is also a whole heap of
unnecessary stores.

> > It shouldn't be a big deal though, there are HW facilities to access
> > the structures "atomically" anyway, due to the caching done by the
> > XIVE.
> 
> Are you suggesting that the PowerNV model should update the VPC, EQC, 
> IVC in the VST accessors before updating the VSTs in RAM ?
> >> 3) A map/unmap interface which gives you / releases a pointer to the
> >> "live" structure.  For powernv that would become
> >> address_space_map()/unmap().  
> 
> yes.
> 
> >> For PAPR it would just be reutn pointer  / no-op.
> 
> ok
> 
> I think I will introduce these handlers progressively in the patchset.
> 
> Thanks,
> 
> C. 
> 
> 

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

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