Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3

2009-09-02 Thread Alexander Graf


On 02.09.2009, at 07:40, Benjamin Herrenschmidt wrote:


On Fri, 2009-07-24 at 18:30 +0200, Alexander Graf wrote:

KVM for PowerPC only supports embedded cores at the moment.

While it makes sense to virtualize on small machines, it's even  
more fun
to do so on big boxes. So I figured we need KVM for PowerPC64 as  
well.


This patchset implements KVM support for Book3s_64 hosts and guest  
support

for Book3s_64 and G3/G4.

To really make use of this, you will also need a modified version  
of qemu
that can deal with KVM on desktop cores. I will send out patches  
for those

later, but want to get feedback on the kernel side first.

In the meanwhile, use the qemu version from
http://www.powerkvm.org/powerkvm.git which already includes all  
required

patches to run G3/G4 and G5 guests.


The git pull request is good when the series is good to pull or for
testing, but for review patches are nice :-)


Ok, guess I'll go back to sending patches in the future then ;-).


So I never got enough time to look into too much details so far
(I'm still up for a little walkthrough on IRC one of these days
btw) but I did look at the changes to the powerpc core code and
they look ok to me.

The only thing I couldn't quite figure out is why you are adding
exports for mm_alloc() and switch_slb().


Well, we need mm_alloc to reserve a VA range. And since that happens  
in module code, it needs to be exported.


As far as switch_slb goes, I think with the new always switch the  
full SLB in entry/exit code logic, that's not required anymore.



I spotted tons of stuff that could be optimized


Yes. It might also be worth collecting all the potential optimizations  
on some wiki, so if someone feels like jumping in on this project, he  
knows where to start. It'd even be good for us, because I always tend  
to forget where exactly the code is the worst :-).



, especially in the
interrupt handling (but then, we all agree that using a magic page
is going to be much better)


The interrupt handling is a separate beast that should be handled more  
generically, but the current code works for KVM at least. Let's take  
baby steps here.



, and I suppose we need to have a close
look at some aspects of the MMU emulation.


I fully agree. The MMU emulation could probably also get quite some  
speedups. For the first version I merely wanted to have something that  
boots and runs Linux.



But for now, I'm happy with the merge, feel free to add my Acked-by,
just make sure it's marked CONFIG_EXPERIMENTAL.


It definitely is experimental still, so yes, I agree.

Should I send out a v4 that removes the slb_switch export and marks  
things as experimental?


Alex

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3

2009-09-02 Thread Benjamin Herrenschmidt
 Well, we need mm_alloc to reserve a VA range. And since that happens  
 in module code, it needs to be exported.

Hrm... I've missed where you call it. Can't you directly allocate
a context ID instead of a whole mm ?

 As far as switch_slb goes, I think with the new always switch the  
 full SLB in entry/exit code logic, that's not required anymore.

Ok. In general, I'd rather keep the KVM SLB switching separate from
the normal one since there's different constraints anyways.

 Should I send out a v4 that removes the slb_switch export and marks  
 things as experimental?

Please, and add my Acks. Pls dbl check the need for mm_alloc() though.

Cheers,
Ben.


--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3

2009-09-02 Thread Alexander Graf


On 02.09.2009, at 08:23, Benjamin Herrenschmidt wrote:


Well, we need mm_alloc to reserve a VA range. And since that happens
in module code, it needs to be exported.


Hrm... I've missed where you call it. Can't you directly allocate
a context ID instead of a whole mm ?


It's in the vcpu init code:

./book3s.c:862: vcpu-arch.mm_guest = mm_alloc();

And the mm_alloc() call was the closest I could find to only allocate  
a context ID. I didn't really want to change too much code in there  
unless I really have to and it seems like mm_alloc doesn't have that  
much overhead.



As far as switch_slb goes, I think with the new always switch the
full SLB in entry/exit code logic, that's not required anymore.


Ok. In general, I'd rather keep the KVM SLB switching separate from
the normal one since there's different constraints anyways.


Yes, that's why we're at v3 already :-).


Should I send out a v4 that removes the slb_switch export and marks
things as experimental?


Please, and add my Acks. Pls dbl check the need for mm_alloc() though.


I'm open for suggestions on how to get a context_id easily/cleanly  
without exporting mm_alloc.


Alex
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3

2009-09-02 Thread Benjamin Herrenschmidt
On Wed, 2009-09-02 at 08:34 +0200, Alexander Graf wrote:
 On 02.09.2009, at 08:23, Benjamin Herrenschmidt wrote:
 
  Well, we need mm_alloc to reserve a VA range. And since that happens
  in module code, it needs to be exported.
 
  Hrm... I've missed where you call it. Can't you directly allocate
  a context ID instead of a whole mm ?
 
 It's in the vcpu init code:
 
 ./book3s.c:862:   vcpu-arch.mm_guest = mm_alloc();
 
 And the mm_alloc() call was the closest I could find to only allocate  
 a context ID. I didn't really want to change too much code in there  
 unless I really have to and it seems like mm_alloc doesn't have that  
 much overhead.

 I'm open for suggestions on how to get a context_id easily/cleanly  
 without exporting mm_alloc.

I see ... init_new_context() and destroy_context() only operate on an
mm_struct... Well, in that case, I'm open to something that would change
those two to __init_new_context() and __destroy_conext() that
respectively return the new ID and take an ID as an argument, which you
can export, and have static inlines in mmu-context.h that implement
init_new_context() and destroy_context() in terms of the above.

Cheers,
Ben.


--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] Add KVM support for Book3s_64 (PPC64) hosts v3

2009-09-02 Thread Hollis Blanchard
On Wed, 2009-09-02 at 15:40 +1000, Benjamin Herrenschmidt wrote:
 On Fri, 2009-07-24 at 18:30 +0200, Alexander Graf wrote:
  KVM for PowerPC only supports embedded cores at the moment.
  
  While it makes sense to virtualize on small machines, it's even more fun
  to do so on big boxes. So I figured we need KVM for PowerPC64 as well.
  
  This patchset implements KVM support for Book3s_64 hosts and guest support
  for Book3s_64 and G3/G4.
  
  To really make use of this, you will also need a modified version of qemu
  that can deal with KVM on desktop cores. I will send out patches for those
  later, but want to get feedback on the kernel side first.
  
  In the meanwhile, use the qemu version from
  http://www.powerkvm.org/powerkvm.git which already includes all required
  patches to run G3/G4 and G5 guests.
 
 The git pull request is good when the series is good to pull or for
 testing, but for review patches are nice :-)

Yeah, I actually went looking for the v3 patchset last week, and gave up
trying to extract it from git...

-- 
Hollis Blanchard
IBM Linux Technology Center

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html