Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

2018-12-13 Thread Richard Henderson
On 12/13/18 5:39 PM, Benjamin Herrenschmidt wrote: > At this point I'd rather not take chances and introduce more bugs, so > I'll post an updated variant with a few fixes but will postpone more > refactoring unless you really really want them now :) No, that's quite all right. Thanks for the

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

2018-12-13 Thread Benjamin Herrenschmidt
On Thu, 2018-11-29 at 11:04 -0800, Richard Henderson wrote: > > While I know the existing code just updates the low 32-bits, I'd rather update > the whole entry, and make use of the old value returned from the cmpxchg. So I had to put this on the back burner for a bit, but I'm back to it now.

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

2018-11-29 Thread Benjamin Herrenschmidt
On Thu, 2018-11-29 at 16:12 -0800, Richard Henderson wrote: > > You mean translating once for the load and for the udpate ? Do you > > expect that translation to have such a significant cost considering > > that all it needs should be in L1 at that point ? > > I guess if the update is rare-ish,

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

2018-11-29 Thread Benjamin Herrenschmidt
On Thu, 2018-11-29 at 16:12 -0800, Richard Henderson wrote: > On 11/29/18 2:54 PM, Benjamin Herrenschmidt wrote: > > > pdpe_addr = (pml4e & PG_ADDRESS_MASK) + > > > (((gphys >> 30) & 0x1ff) << 3); > > > pdpe = x86_ldq_phys(cs, pdpe_addr); > > > do { > > >

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

2018-11-29 Thread Richard Henderson
On 11/29/18 2:54 PM, Benjamin Herrenschmidt wrote: >> pdpe_addr = (pml4e & PG_ADDRESS_MASK) + >> (((gphys >> 30) & 0x1ff) << 3); >> pdpe = x86_ldq_phys(cs, pdpe_addr); >> do { >> if (!(pdpe & PG_PRESENT_MASK)) { >> goto do_fault; >> } >>

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

2018-11-29 Thread Benjamin Herrenschmidt
On Thu, 2018-11-29 at 11:04 -0800, Richard Henderson wrote: > On 11/28/18 3:15 PM, Benjamin Herrenschmidt wrote: > > +static inline uint64_t update_entry(CPUState *cs, target_ulong addr, > > +uint64_t orig_entry, uint32_t bits) > > +{ > > +uint64_t new_entry

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

2018-11-29 Thread Richard Henderson
On 11/28/18 3:15 PM, Benjamin Herrenschmidt wrote: > +static inline uint64_t update_entry(CPUState *cs, target_ulong addr, > +uint64_t orig_entry, uint32_t bits) > +{ > +uint64_t new_entry = orig_entry | bits; > + > +/* Write the updated bottom 32-bits

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

2018-11-29 Thread Paolo Bonzini
On 29/11/18 11:04, Benjamin Herrenschmidt wrote: > On Thu, 2018-11-29 at 10:26 +0100, Paolo Bonzini wrote: >> On 29/11/18 00:15, Benjamin Herrenschmidt wrote: >>> Afaik, this isn't well documented (at least it wasn't when I last looked) >>> but OSes such as Linux rely on this behaviour: >>> >>>

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

2018-11-29 Thread Benjamin Herrenschmidt
On Thu, 2018-11-29 at 10:26 +0100, Paolo Bonzini wrote: > On 29/11/18 00:15, Benjamin Herrenschmidt wrote: > > Afaik, this isn't well documented (at least it wasn't when I last looked) > > but OSes such as Linux rely on this behaviour: > > > > The HW updates to the page tables need to be done

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

2018-11-29 Thread Paolo Bonzini
On 29/11/18 00:15, Benjamin Herrenschmidt wrote: > Afaik, this isn't well documented (at least it wasn't when I last looked) > but OSes such as Linux rely on this behaviour: > > The HW updates to the page tables need to be done atomically with the > checking of the present bit (and other

[Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

2018-11-28 Thread Benjamin Herrenschmidt
Afaik, this isn't well documented (at least it wasn't when I last looked) but OSes such as Linux rely on this behaviour: The HW updates to the page tables need to be done atomically with the checking of the present bit (and other permissions). This is what allows Linux to do simple xchg of PTEs