RE: Mapping magic page from host side

2012-05-29 Thread Sethi Varun-B16395
Hi Dushyant,
I think that may be you should allow guest to complete some basic 
initialization, for example create proper MMU mappings for itself.
Are you sure that magic page tlb entry didn't get overwritten by some other 
guest tlb entry?

-Varun

> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-
> ow...@vger.kernel.org] On Behalf Of cs5070214
> Sent: Tuesday, May 29, 2012 8:12 PM
> To: kvm-ppc@vger.kernel.org
> Subject: Mapping magic page from host side
> 
> Hi,
> 
>We are trying to do the patching of the privileged instructions of
> guest from host side (instead of guest kernel patching itself). For this
> we first need to map the magic page which is currently being done via
> hypercall from guest.
> 
> We tried a few approaches. When we map the magic page in the emulation
> code for the first exit due to MTMSR, it works and guest boots fine. But
> if we try to map the page on the first exit due to any privileged exits,
> the guest does not boot and it gives an error.
> 
> =
> 
> Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=8 P2020 RDB
> Modules linked in:
> NIP: c005811c LR: c0052284 CTR: c02e59cc
> REGS: d81dd9b0 TRAP: 0300   Not tainted  (3.0.0-rc4-g832abe3-dirty)
> MSR: 00029200   CR: 2224  XER: 2000
> DEAR: e11cec14, ESR: 
> TASK = dc902a00[1267] 'qemu-system-ppc' THREAD: d81dc000 CPU: 0
> GPR00: e104a7d0 d81dda60 dc902a00 d809 e11cec10 c051 c02e68f8
> 277420
> GPR08: c06f5290 d80cfffc c0720558 d81dda70 8224  d809
> 00
> GPR16:       
> 00
> GPR24:   c072 c051 d99c d809 f000
> d81dda NIP [c005811c] kvmppc_mmu_xlate+0x40/0xc4 LR [c0052284]
> kvmppc_read_guest+0x48/0xb0
> =
> 
> 
> My question is are there any prerequisites that needs to be satisfied
> before we map the magic page and what would be the proper place to do it?
> 
> 
> Thanks and Regards,
> Dushyant Bansal
> --
> 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

N�r��yb�X��ǧv�^�)޺{.n�+jir)w*jg����ݢj/���z�ޖ��2�ޙ&�)ߡ�a�����G���h��j:+v���w��٥

RE: Mapping magic page from host side

2012-05-29 Thread Bhushan Bharat-R65777


> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
> Behalf Of cs5070214
> Sent: Tuesday, May 29, 2012 8:12 PM
> To: kvm-ppc@vger.kernel.org
> Subject: Mapping magic page from host side
> 
> Hi,
> 
>We are trying to do the patching of the privileged instructions of
> guest from host side (instead of guest kernel patching itself). For this
> we first need to map the magic page which is currently being done via
> hypercall from guest.
> 
> We tried a few approaches. When we map the magic page in the emulation
> code for the first exit due to MTMSR, it works and guest boots fine. But
> if we try to map the page on the first exit due to any privileged exits,
> the guest does not boot and it gives an error.
> 
> =
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=8 P2020 RDB
> Modules linked in:
> NIP: c005811c LR: c0052284 CTR: c02e59cc
> REGS: d81dd9b0 TRAP: 0300   Not tainted  (3.0.0-rc4-g832abe3-dirty)
> MSR: 00029200   CR: 2224  XER: 2000
> DEAR: e11cec14, ESR: 
> TASK = dc902a00[1267] 'qemu-system-ppc' THREAD: d81dc000 CPU: 0
> GPR00: e104a7d0 d81dda60 dc902a00 d809 e11cec10 c051 c02e68f8
> 277420
> GPR08: c06f5290 d80cfffc c0720558 d81dda70 8224  d809
> 00
> GPR16:       
> 00
> GPR24:   c072 c051 d99c d809 f000
> d81dda
> NIP [c005811c] kvmppc_mmu_xlate+0x40/0xc4
> LR [c0052284] kvmppc_read_guest+0x48/0xb0
> =
> 
> My question is are there any prerequisites that needs to be satisfied
> before we map the magic page and what would be the proper place to do
> it?

Can we try mapping before we does first lightweight exit?

Thanks
-Bharat
> 
> 
> Thanks and Regards,
> Dushyant Bansal
> --
> 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