diff for duplicates of <1373481426.8183.219@snotra> diff --git a/a/1.txt b/N1/1.txt index 0633e30..55ac31b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,55 +1,55 @@ On 07/10/2013 05:18:10 AM, Alexander Graf wrote: -> +>=20 > On 10.07.2013, at 02:12, Scott Wood wrote: -> +>=20 > > On 07/09/2013 04:45:10 PM, Alexander Graf wrote: > >> On 28.06.2013, at 11:20, Mihai Caraman wrote: > >> > + /* Get page size */ -> >> > + if (MAS0_GET_TLBSEL(mfspr(SPRN_MAS0)) = 0) -> >> > + psize_shift = PAGE_SHIFT; +> >> > + if (MAS0_GET_TLBSEL(mfspr(SPRN_MAS0)) =3D=3D 0) +> >> > + psize_shift =3D PAGE_SHIFT; > >> > + else -> >> > + psize_shift = MAS1_GET_TSIZE(mas1) + 10; +> >> > + psize_shift =3D MAS1_GET_TSIZE(mas1) + 10; > >> > + -> >> > + mas7_mas3 = (((u64) mfspr(SPRN_MAS7)) << 32) | +> >> > + mas7_mas3 =3D (((u64) mfspr(SPRN_MAS7)) << 32) | > >> > + mfspr(SPRN_MAS3); -> >> > + addr = (mas7_mas3 & (~0ULL << psize_shift)) | +> >> > + addr =3D (mas7_mas3 & (~0ULL << psize_shift)) | > >> > + (geaddr & ((1ULL << psize_shift) - 1ULL)); > >> > + > >> > + /* Map a page and get guest's instruction */ -> >> > + page = pfn_to_page(addr >> PAGE_SHIFT); -> >> While looking at this I just realized that you're missing a check -> here. What if our IP is in some PCI BAR? Or can't we execute from +> >> > + page =3D pfn_to_page(addr >> PAGE_SHIFT); +> >> While looking at this I just realized that you're missing a check =20 +> here. What if our IP is in some PCI BAR? Or can't we execute from =20 > those? > > -> > We at least need to check pfn_valid() first. That'll just keep us -> from accessing a bad pointer in the host kernel, though -- it won't -> make the emulation actually work. If we need that, we'll probably +> > We at least need to check pfn_valid() first. That'll just keep us =20 +> from accessing a bad pointer in the host kernel, though -- it won't =20 +> make the emulation actually work. If we need that, we'll probably =20 > need to create a temporary TLB entry manually. -> +>=20 > ioremap()? -That's a bit heavy... also we'd need to deal with cacheability. This -code is already engaged in directly creating TLB entries, so it doesn't -seem like much of a stretch to create one for this. It should be +That's a bit heavy... also we'd need to deal with cacheability. This =20 +code is already engaged in directly creating TLB entries, so it doesn't =20 +seem like much of a stretch to create one for this. It should be =20 faster than ioremap() or kmap_atomic(). -The one complication is allocating the virtual address space, but maybe -we could just use the page that kmap_atomic would have used? Of -course, if we want to handle execution from other than normal kernel -memory, we'll need to make sure that the virtual address space is +The one complication is allocating the virtual address space, but maybe =20 +we could just use the page that kmap_atomic would have used? Of =20 +course, if we want to handle execution from other than normal kernel =20 +memory, we'll need to make sure that the virtual address space is =20 allocated even when highmem is not present (e.g. 64-bit). -> However, if we were walking the guest TLB cache instead we would get -> a guest physical address which we can always resolve to a host +> However, if we were walking the guest TLB cache instead we would get =20 +> a guest physical address which we can always resolve to a host =20 > virtual address. -> -> I'm not sure how important that whole use case is though. Maybe we +>=20 +> I'm not sure how important that whole use case is though. Maybe we =20 > should just error out to the guest for now. -It's not that important, now that we are using hugetlb rather than -directly mapping a large hunk of reserved memory. It would be nice to -handle it though, if we can do without too much hassle. And I think -manually creating a TLB entry could be faster than kmap_atomic(), or +It's not that important, now that we are using hugetlb rather than =20 +directly mapping a large hunk of reserved memory. It would be nice to =20 +handle it though, if we can do without too much hassle. And I think =20 +manually creating a TLB entry could be faster than kmap_atomic(), or =20 searching the guest TLB and then doing a reverse memslot lookup. --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index 096c1e2..2230b66 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,68 +1,68 @@ "ref\027E6FCB1-322F-410D-A87C-D5410C7374E7@suse.de\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH 2/2] KVM: PPC: Book3E: Get vcpu's last instruction for emulation\0" - "Date\0Wed, 10 Jul 2013 18:37:06 +0000\0" + "Date\0Wed, 10 Jul 2013 13:37:06 -0500\0" "To\0Alexander Graf <agraf@suse.de>\0" "Cc\0Mihai Caraman <mihai.caraman@freescale.com>" - kvm-ppc@vger.kernel.org + linuxppc-dev@lists.ozlabs.org kvm@vger.kernel.org - " linuxppc-dev@lists.ozlabs.org\0" + " kvm-ppc@vger.kernel.org\0" "\00:1\0" "b\0" "On 07/10/2013 05:18:10 AM, Alexander Graf wrote:\n" - "> \n" + ">=20\n" "> On 10.07.2013, at 02:12, Scott Wood wrote:\n" - "> \n" + ">=20\n" "> > On 07/09/2013 04:45:10 PM, Alexander Graf wrote:\n" "> >> On 28.06.2013, at 11:20, Mihai Caraman wrote:\n" "> >> > +\t/* Get page size */\n" - "> >> > +\tif (MAS0_GET_TLBSEL(mfspr(SPRN_MAS0)) = 0)\n" - "> >> > +\t\tpsize_shift = PAGE_SHIFT;\n" + "> >> > +\tif (MAS0_GET_TLBSEL(mfspr(SPRN_MAS0)) =3D=3D 0)\n" + "> >> > +\t\tpsize_shift =3D PAGE_SHIFT;\n" "> >> > +\telse\n" - "> >> > +\t\tpsize_shift = MAS1_GET_TSIZE(mas1) + 10;\n" + "> >> > +\t\tpsize_shift =3D MAS1_GET_TSIZE(mas1) + 10;\n" "> >> > +\n" - "> >> > +\tmas7_mas3 = (((u64) mfspr(SPRN_MAS7)) << 32) |\n" + "> >> > +\tmas7_mas3 =3D (((u64) mfspr(SPRN_MAS7)) << 32) |\n" "> >> > +\t\t mfspr(SPRN_MAS3);\n" - "> >> > +\taddr = (mas7_mas3 & (~0ULL << psize_shift)) |\n" + "> >> > +\taddr =3D (mas7_mas3 & (~0ULL << psize_shift)) |\n" "> >> > +\t (geaddr & ((1ULL << psize_shift) - 1ULL));\n" "> >> > +\n" "> >> > +\t/* Map a page and get guest's instruction */\n" - "> >> > +\tpage = pfn_to_page(addr >> PAGE_SHIFT);\n" - "> >> While looking at this I just realized that you're missing a check \n" - "> here. What if our IP is in some PCI BAR? Or can't we execute from \n" + "> >> > +\tpage =3D pfn_to_page(addr >> PAGE_SHIFT);\n" + "> >> While looking at this I just realized that you're missing a check =20\n" + "> here. What if our IP is in some PCI BAR? Or can't we execute from =20\n" "> those?\n" "> >\n" - "> > We at least need to check pfn_valid() first. That'll just keep us \n" - "> from accessing a bad pointer in the host kernel, though -- it won't \n" - "> make the emulation actually work. If we need that, we'll probably \n" + "> > We at least need to check pfn_valid() first. That'll just keep us =20\n" + "> from accessing a bad pointer in the host kernel, though -- it won't =20\n" + "> make the emulation actually work. If we need that, we'll probably =20\n" "> need to create a temporary TLB entry manually.\n" - "> \n" + ">=20\n" "> ioremap()?\n" "\n" - "That's a bit heavy... also we'd need to deal with cacheability. This \n" - "code is already engaged in directly creating TLB entries, so it doesn't \n" - "seem like much of a stretch to create one for this. It should be \n" + "That's a bit heavy... also we'd need to deal with cacheability. This =20\n" + "code is already engaged in directly creating TLB entries, so it doesn't =20\n" + "seem like much of a stretch to create one for this. It should be =20\n" "faster than ioremap() or kmap_atomic().\n" "\n" - "The one complication is allocating the virtual address space, but maybe \n" - "we could just use the page that kmap_atomic would have used? Of \n" - "course, if we want to handle execution from other than normal kernel \n" - "memory, we'll need to make sure that the virtual address space is \n" + "The one complication is allocating the virtual address space, but maybe =20\n" + "we could just use the page that kmap_atomic would have used? Of =20\n" + "course, if we want to handle execution from other than normal kernel =20\n" + "memory, we'll need to make sure that the virtual address space is =20\n" "allocated even when highmem is not present (e.g. 64-bit).\n" "\n" - "> However, if we were walking the guest TLB cache instead we would get \n" - "> a guest physical address which we can always resolve to a host \n" + "> However, if we were walking the guest TLB cache instead we would get =20\n" + "> a guest physical address which we can always resolve to a host =20\n" "> virtual address.\n" - "> \n" - "> I'm not sure how important that whole use case is though. Maybe we \n" + ">=20\n" + "> I'm not sure how important that whole use case is though. Maybe we =20\n" "> should just error out to the guest for now.\n" "\n" - "It's not that important, now that we are using hugetlb rather than \n" - "directly mapping a large hunk of reserved memory. It would be nice to \n" - "handle it though, if we can do without too much hassle. And I think \n" - "manually creating a TLB entry could be faster than kmap_atomic(), or \n" + "It's not that important, now that we are using hugetlb rather than =20\n" + "directly mapping a large hunk of reserved memory. It would be nice to =20\n" + "handle it though, if we can do without too much hassle. And I think =20\n" + "manually creating a TLB entry could be faster than kmap_atomic(), or =20\n" "searching the guest TLB and then doing a reverse memslot lookup.\n" "\n" - -Scott + -Scott= -357bbe893ea8bff6a049c4f8b602dbcfd3454bd277cc796d678fed83f72057ca +d925f454e54fdc9560e29d7b28a2943bac58116a26dab1f5ed4f176d502ae297
diff --git a/a/1.txt b/N2/1.txt index 0633e30..2fdf218 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -5,7 +5,7 @@ On 07/10/2013 05:18:10 AM, Alexander Graf wrote: > > On 07/09/2013 04:45:10 PM, Alexander Graf wrote: > >> On 28.06.2013, at 11:20, Mihai Caraman wrote: > >> > + /* Get page size */ -> >> > + if (MAS0_GET_TLBSEL(mfspr(SPRN_MAS0)) = 0) +> >> > + if (MAS0_GET_TLBSEL(mfspr(SPRN_MAS0)) == 0) > >> > + psize_shift = PAGE_SHIFT; > >> > + else > >> > + psize_shift = MAS1_GET_TSIZE(mas1) + 10; diff --git a/a/content_digest b/N2/content_digest index 096c1e2..482ed9a 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,12 +1,12 @@ "ref\027E6FCB1-322F-410D-A87C-D5410C7374E7@suse.de\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH 2/2] KVM: PPC: Book3E: Get vcpu's last instruction for emulation\0" - "Date\0Wed, 10 Jul 2013 18:37:06 +0000\0" + "Date\0Wed, 10 Jul 2013 13:37:06 -0500\0" "To\0Alexander Graf <agraf@suse.de>\0" "Cc\0Mihai Caraman <mihai.caraman@freescale.com>" - kvm-ppc@vger.kernel.org - kvm@vger.kernel.org - " linuxppc-dev@lists.ozlabs.org\0" + <kvm-ppc@vger.kernel.org> + <kvm@vger.kernel.org> + " <linuxppc-dev@lists.ozlabs.org>\0" "\00:1\0" "b\0" "On 07/10/2013 05:18:10 AM, Alexander Graf wrote:\n" @@ -16,7 +16,7 @@ "> > On 07/09/2013 04:45:10 PM, Alexander Graf wrote:\n" "> >> On 28.06.2013, at 11:20, Mihai Caraman wrote:\n" "> >> > +\t/* Get page size */\n" - "> >> > +\tif (MAS0_GET_TLBSEL(mfspr(SPRN_MAS0)) = 0)\n" + "> >> > +\tif (MAS0_GET_TLBSEL(mfspr(SPRN_MAS0)) == 0)\n" "> >> > +\t\tpsize_shift = PAGE_SHIFT;\n" "> >> > +\telse\n" "> >> > +\t\tpsize_shift = MAS1_GET_TSIZE(mas1) + 10;\n" @@ -65,4 +65,4 @@ "\n" -Scott -357bbe893ea8bff6a049c4f8b602dbcfd3454bd277cc796d678fed83f72057ca +f7e58e30e785e9a87e6596172e7e61eb1feeeb5eea1430826e8fc0cf66b18349
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.