Re: [kvm-ppc-devel] [PATCH] [1/4] Add per guest pvr

[Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>]

Hollis Blanchard wrote:
> On Wed, 2008-01-30 at 13:31 +0100, ehrhardt@linux.vnet.ibm.com wrote:
>> This adds get/set pvr to differ wanted guest cpu on runtiome.
>> The intention to bring it up so early at the vm ioctl is that our kernel code
>> can not know if which guest type we want to create on vcpu_create. Vcpu_create
>> itself do not transport any structure and and is called before our hooks in
>> the machine initialization.
> 
> The analogue for x86 is cpuid, and that's handled as a vcpu ioctl. Of
> course, they don't go all the way with it, because their guests are
> somewhat tied to the host hardware (hardware manages e.g. guest register
> state).
> 
>> We want to have our implementation ready to run different guest types at the
>> same time, therefore we can't set this globally at the /dev/kvm ioctl.
>> Currently this sets the pvr per machine while in the architecture itself it
>> is a per processor attribute (this binds us to one processor type per virtual
>> machine). If needed we might change this so that vcpu_create uses the last set
>> vm pvr as pvr for a new cpu e.g create generic followed by coprocesser
>> sequentially - comments?
> 
> Yes, I really don't like it. :) I think this should be a per-vcpu ioctl,
> and then we must make sure we've allocated enough vcpu memory for any
> guest architecture type (see vcpu_size as passed to kvm_init()).

ok, fine for me. It was you who suggested that we need it on create, but allocating
enough for all possible cases is ok for me. I'll change the pvr stuff.
 
>> Additionally this may later be extended to select the real pvr that e.g. 
>> will be presented to what a guest sees on a read to that spr. here the patch
>> as it is atm folowed by the tlb patch that uses the function to select the
>> right tlb layout.
> 
> Why aren't you using real PVR numbers already?

To be honest I did not want to decide which of the numerous 440 types I should set
and I didn't need to use that pvr&mask match atm.
 
> Anyways, this probably isn't worth spending too much time on now. The
> immediate need is for the TLB accessors, and I think we can base those
> on the PVR without a full multi-arch guest solution.

I'll let it be virtual pvr's - we can change them later without issues anyway.


-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel