| Message ID | 20150615172804.22475.7018.stgit@bahia.huguette.org |
|---|---|
| State | New |
| Headers | show |
On 06/16/2015 03:28 AM, Greg Kurz wrote: > According to PAPR+ 3.2.2.2, the TCE is implemented as follows: > bits 0-51: real page number > bits 52-61: reserved for future use > bits 62-63: page protection (read-only, write-only, read-write) tce_list is not a TCE, it is "The logical address of a page of (4 K long on a 4 K boundary) of TCE contents to be stored in the TCE table (contains logical address of storage page to be mapped)" so we rather want to remove (tce_list & ~SPAPR_TCE_RW) below. > Possible values for the protection bits are necessarly non-zero and thus > H_PUT_TCE_INDIRECT currently always fails and returns H_PARAMETER. > > The code explicitly clears the protection bits when computing the TCE offset, > a few lines below (tce_list & ~SPAPR_TCE_RW)... The sanity check is obviously > wrong for these bits. > > Moreover, I could find no indication in PAPR+ that using the other reserved > bits should error out with H_PARAMETER. > > This patch simply drops the offending check. > > Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com> > --- > hw/ppc/spapr_iommu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/ppc/spapr_iommu.c b/hw/ppc/spapr_iommu.c > index 8cd9dba9ac4d..37a1110c9d87 100644 > --- a/hw/ppc/spapr_iommu.c > +++ b/hw/ppc/spapr_iommu.c > @@ -258,7 +258,7 @@ static target_ulong h_put_tce_indirect(PowerPCCPU *cpu, > return H_PARAMETER; > } > > - if ((npages > 512) || (tce_list & SPAPR_TCE_PAGE_MASK)) { > + if (npages > 512) { > return H_PARAMETER; > } > > >
On Tue, 16 Jun 2015 18:53:51 +1000 Alexey Kardashevskiy <aik@ozlabs.ru> wrote: > On 06/16/2015 03:28 AM, Greg Kurz wrote: > > According to PAPR+ 3.2.2.2, the TCE is implemented as follows: > > bits 0-51: real page number > > bits 52-61: reserved for future use > > bits 62-63: page protection (read-only, write-only, read-write) > > > > tce_list is not a TCE, it is "The logical address of a page of (4 K long on > a 4 K boundary) of TCE contents to be stored in the TCE table (contains > logical address of storage page to be mapped)" so we rather want to remove > (tce_list & ~SPAPR_TCE_RW) below. > Oops my bad for the confustion... :-\ Then it looks like SPAPR_TCE_RW can be dropped as well since put_tce_emu() uses IOMMU_RW instead. > > > Possible values for the protection bits are necessarly non-zero and thus > > H_PUT_TCE_INDIRECT currently always fails and returns H_PARAMETER. > > > > The code explicitly clears the protection bits when computing the TCE offset, > > a few lines below (tce_list & ~SPAPR_TCE_RW)... The sanity check is obviously > > wrong for these bits. > > > > Moreover, I could find no indication in PAPR+ that using the other reserved > > bits should error out with H_PARAMETER. > > > > This patch simply drops the offending check. > > > > Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com> > > --- > > hw/ppc/spapr_iommu.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/hw/ppc/spapr_iommu.c b/hw/ppc/spapr_iommu.c > > index 8cd9dba9ac4d..37a1110c9d87 100644 > > --- a/hw/ppc/spapr_iommu.c > > +++ b/hw/ppc/spapr_iommu.c > > @@ -258,7 +258,7 @@ static target_ulong h_put_tce_indirect(PowerPCCPU *cpu, > > return H_PARAMETER; > > } > > > > - if ((npages > 512) || (tce_list & SPAPR_TCE_PAGE_MASK)) { > > + if (npages > 512) { > > return H_PARAMETER; > > } > > > > > > > >
On 06/16/2015 07:24 PM, Greg Kurz wrote: > On Tue, 16 Jun 2015 18:53:51 +1000 > Alexey Kardashevskiy <aik@ozlabs.ru> wrote: > >> On 06/16/2015 03:28 AM, Greg Kurz wrote: >>> According to PAPR+ 3.2.2.2, the TCE is implemented as follows: >>> bits 0-51: real page number >>> bits 52-61: reserved for future use >>> bits 62-63: page protection (read-only, write-only, read-write) >> >> >> >> tce_list is not a TCE, it is "The logical address of a page of (4 K long on >> a 4 K boundary) of TCE contents to be stored in the TCE table (contains >> logical address of storage page to be mapped)" so we rather want to remove >> (tce_list & ~SPAPR_TCE_RW) below. >> > > Oops my bad for the confustion... :-\ > > Then it looks like SPAPR_TCE_RW can be dropped as well since put_tce_emu() uses > IOMMU_RW instead. Well, spapr_tce_translate_iommu() should actually translate SPAPR_TCE_xxx (PAPR defined flags) to IOMMU_xxx (QEMU IOMMUTLBEntry permission bits), not just rely on the fact that they match. > >> >>> Possible values for the protection bits are necessarly non-zero and thus >>> H_PUT_TCE_INDIRECT currently always fails and returns H_PARAMETER. >>> >>> The code explicitly clears the protection bits when computing the TCE offset, >>> a few lines below (tce_list & ~SPAPR_TCE_RW)... The sanity check is obviously >>> wrong for these bits. >>> >>> Moreover, I could find no indication in PAPR+ that using the other reserved >>> bits should error out with H_PARAMETER. >>> >>> This patch simply drops the offending check. >>> >>> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com> >>> --- >>> hw/ppc/spapr_iommu.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/hw/ppc/spapr_iommu.c b/hw/ppc/spapr_iommu.c >>> index 8cd9dba9ac4d..37a1110c9d87 100644 >>> --- a/hw/ppc/spapr_iommu.c >>> +++ b/hw/ppc/spapr_iommu.c >>> @@ -258,7 +258,7 @@ static target_ulong h_put_tce_indirect(PowerPCCPU *cpu, >>> return H_PARAMETER; >>> } >>> >>> - if ((npages > 512) || (tce_list & SPAPR_TCE_PAGE_MASK)) { >>> + if (npages > 512) { >>> return H_PARAMETER; >>> } >>> >>> >>> >> >> >
diff --git a/hw/ppc/spapr_iommu.c b/hw/ppc/spapr_iommu.c index 8cd9dba9ac4d..37a1110c9d87 100644 --- a/hw/ppc/spapr_iommu.c +++ b/hw/ppc/spapr_iommu.c @@ -258,7 +258,7 @@ static target_ulong h_put_tce_indirect(PowerPCCPU *cpu, return H_PARAMETER; } - if ((npages > 512) || (tce_list & SPAPR_TCE_PAGE_MASK)) { + if (npages > 512) { return H_PARAMETER; }
According to PAPR+ 3.2.2.2, the TCE is implemented as follows: bits 0-51: real page number bits 52-61: reserved for future use bits 62-63: page protection (read-only, write-only, read-write) Possible values for the protection bits are necessarly non-zero and thus H_PUT_TCE_INDIRECT currently always fails and returns H_PARAMETER. The code explicitly clears the protection bits when computing the TCE offset, a few lines below (tce_list & ~SPAPR_TCE_RW)... The sanity check is obviously wrong for these bits. Moreover, I could find no indication in PAPR+ that using the other reserved bits should error out with H_PARAMETER. This patch simply drops the offending check. Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com> --- hw/ppc/spapr_iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)