On 02/16/2012 09:34 PM, Alexander Graf wrote: > On 16.02.2012, at 20:24, Avi Kivity wrote: > > > On 02/15/2012 04:08 PM, Alexander Graf wrote: > >>> > >>> Well, the scatter/gather registers I proposed will give you just one > >>> register or all of them. > >> > >> One register is hardly any use. We either need all ways of a respective > >> address to do a full fledged lookup or all of them. > > > > I should have said, just one register, or all of them, or anything in > > between. > > > >> By sharing the same data structures between qemu and kvm, we actually > >> managed to reuse all of the tcg code for lookups, just like you do for x86. > > > > Sharing the data structures is not need. Simply synchronize them before > > lookup, like we do for ordinary registers. > > Ordinary registers are a few bytes. We're talking of dozens of kbytes here.
A TLB way is a few dozen bytes, no? > > > >> On x86 you also have shared memory for page tables, it's just guest > >> visible, hence in guest memory. The concept is the same. > > > > But cr3 isn't, and if we put it in shared memory, we'd have to VMREAD it > > on every exit. And you're risking the same thing if your hardware gets > > cleverer. > > Yes, we do. When that day comes, we forget the CAP and do it another way. > Which way we will find out by the time that day of more clever hardware comes > :). Or we try to be less clever unless we have a really compelling reason. qemu monitor and gdb support aren't compelling reasons to optimize. > > > > It's too magical, fitting a random version of a random userspace > > component. Now you can't change this tcg code (and still keep the magic). > > > > Some complexity is part of keeping software as separate components. > > Why? If another user space wants to use this, they can > > a) do the slow copy path > or > b) simply use our struct definitions > > The whole copy thing really only makes sense when you have existing code in > user space that you don't want to touch, but easily add on KVM to it. If KVM > is part of your whole design, then integrating things makes a lot more sense. Yeah, I guess. > > > > >> There are essentially no if(kvm_enabled)'s in our MMU walking code, > >> because the tables are just there. Makes everything a lot easier (without > >> dragging down performance). > > > > We have the same issue with registers. There we call > > cpu_synchronize_state() before every access. No magic, but we get to > > reuse the code just the same. > > Yes, and for those few bytes it's ok to do so - most of the time. On s390, > even those get shared by now. And it makes sense to do so - if we synchronize > it every time anyways, why not do so implicitly? > At least on x86, we synchronize only rarely. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
