Re: [PATCH v2 2/5] ia64: reuse append_elf_note() and final_note() functions

[Dave Young]

Hi Hari

Personally I like V1 more, but split the patch 2 is easier for ia64
people to reivew.  I did basic x86 testing, it runs ok.

On 11/25/16 at 05:24pm, Hari Bathini wrote:
> Get rid of multiple definitions of append_elf_note() & final_note()
> functions. Reuse these functions compiled under CONFIG_CRASH_CORE.
> 
> Signed-off-by: Hari Bathini 
> ---
>  arch/ia64/kernel/crash.c   |   22 --
>  include/linux/crash_core.h |4 
>  kernel/crash_core.c|6 +++---
>  kernel/kexec_core.c|   28 
>  4 files changed, 7 insertions(+), 53 deletions(-)
> 
> diff --git a/arch/ia64/kernel/crash.c b/arch/ia64/kernel/crash.c
> index 2955f35..75859a0 100644
> --- a/arch/ia64/kernel/crash.c
> +++ b/arch/ia64/kernel/crash.c
> @@ -27,28 +27,6 @@ static int kdump_freeze_monarch;
>  static int kdump_on_init = 1;
>  static int kdump_on_fatal_mca = 1;
>  
> -static inline Elf64_Word
> -*append_elf_note(Elf64_Word *buf, char *name, unsigned type, void *data,
> - size_t data_len)
> -{
> - struct elf_note *note = (struct elf_note *)buf;
> - note->n_namesz = strlen(name) + 1;
> - note->n_descsz = data_len;
> - note->n_type   = type;
> - buf += (sizeof(*note) + 3)/4;
> - memcpy(buf, name, note->n_namesz);
> - buf += (note->n_namesz + 3)/4;
> - memcpy(buf, data, data_len);
> - buf += (data_len + 3)/4;
> - return buf;
> -}
> -
> -static void
> -final_note(void *buf)
> -{
> - memset(buf, 0, sizeof(struct elf_note));
> -}
> -

The above IA64 version looks better than the functions in kexec_core.c
about the Elf64_Word type usage and the simpler final_note function.

Care to update crash_core.c to use this instead?

Otherwise I'm fine with the changes.

>  extern void ia64_dump_cpu_regs(void *);
>  
>  static DEFINE_PER_CPU(struct elf_prstatus, elf_prstatus);
> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> index 9a4f4b0..2ae20b1 100644
> --- a/include/linux/crash_core.h
> +++ b/include/linux/crash_core.h
> @@ -61,6 +61,10 @@ extern u32 vmcoreinfo_note[VMCOREINFO_NOTE_SIZE/4];
>  extern size_t vmcoreinfo_size;
>  extern size_t vmcoreinfo_max_size;
>  
> +u32 *append_elf_note(u32 *buf, char *name, unsigned int type,
> +  void *data, size_t data_len);
> +void final_note(u32 *buf);
> +
>  int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
>   unsigned long long *crash_size, unsigned long long *crash_base);
>  int parse_crashkernel_high(char *cmdline, unsigned long long system_ram,
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index 60a98fc..9223976 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -291,8 +291,8 @@ int __init parse_crashkernel_low(char *cmdline,
>   "crashkernel=", suffix_tbl[SUFFIX_LOW]);
>  }
>  
> -static u32 *append_elf_note(u32 *buf, char *name, unsigned int type,
> - void *data, size_t data_len)
> +u32 *append_elf_note(u32 *buf, char *name, unsigned int type,
> +  void *data, size_t data_len)
>  {
>   struct elf_note note;
>  
> @@ -309,7 +309,7 @@ static u32 *append_elf_note(u32 *buf, char *name, 
> unsigned int type,
>   return buf;
>  }
>  
> -static void final_note(u32 *buf)
> +void final_note(u32 *buf)
>  {
>   struct elf_note note;
>  
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 3aa21f3..596cb32 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -988,34 +988,6 @@ int crash_shrink_memory(unsigned long new_size)
>   return ret;
>  }
>  
> -static u32 *append_elf_note(u32 *buf, char *name, unsigned type, void *data,
> - size_t data_len)
> -{
> - struct elf_note note;
> -
> - note.n_namesz = strlen(name) + 1;
> - note.n_descsz = data_len;
> - note.n_type   = type;
> - memcpy(buf, , sizeof(note));
> - buf += (sizeof(note) + 3)/4;
> - memcpy(buf, name, note.n_namesz);
> - buf += (note.n_namesz + 3)/4;
> - memcpy(buf, data, note.n_descsz);
> - buf += (note.n_descsz + 3)/4;
> -
> - return buf;
> -}
> -
> -static void final_note(u32 *buf)
> -{
> - struct elf_note note;
> -
> - note.n_namesz = 0;
> - note.n_descsz = 0;
> - note.n_type   = 0;
> - memcpy(buf, , sizeof(note));
> -}
> -
>  void crash_save_cpu(struct pt_regs *regs, int cpu)
>  {
>   struct elf_prstatus prstatus;
> 
> 
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Thanks
Dave

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCHv4 07/10] kexec: Switch to __pa_symbol

[Dave Young]

On 11/30/16 at 09:13pm, Eric W. Biederman wrote:
> Dave Young  writes:
> 
> > Hi, Laura
> > On 11/29/16 at 10:55am, Laura Abbott wrote:
> >> 
> >> __pa_symbol is the correct api to get the physical address of kernel
> >> symbols. Switch to it to allow for better debug checking.
> >> 
> >
> > I assume __pa_symbol is faster than __pa, but it still need some testing
> > on all arches which support kexec.
> >
> > But seems long long ago there is a commit e3ebadd95cb in the commit log
> > I see below from:
> > "we should deprecate __pa_symbol(), and preferably __pa() too - and
> >  just use "virt_to_phys()" instead, which is is more readable and has
> >  nicer semantics."
> >
> > But maybe in modern code __pa_symbol is prefered I may miss background.
> > virt_to_phys still sounds more readable now for me though.
> 
> There has been a lot of history with the various definitions.
> __pa_symbol used to be x86 specific.
> 
> Now what we have is that __pa_symbol is just __pa(RELOC_HIDE(x));
> 
> Now arguably that whole reloc hide thing should happen by architectures
> having a non-inline version of __pa as was done in the commit you
> mention.  But at this point there appears to be nothing wrong with
> changing a __pa to a __pa_symbol it might make things a tad more
> reliable depending on the implementation of __pa.

Then it is safe and reasonable, thanks for the clarification. 

> 
> Acked-by: "Eric W. Biederman" 
> 
> 
> Eric
> 
> >> Signed-off-by: Laura Abbott 
> >> ---
> >> Found during review of the kernel. Untested.
> >> ---
> >>  kernel/kexec_core.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> >> index 5616755..e1b625e 100644
> >> --- a/kernel/kexec_core.c
> >> +++ b/kernel/kexec_core.c
> >> @@ -1397,7 +1397,7 @@ void __weak arch_crash_save_vmcoreinfo(void)
> >>  
> >>  phys_addr_t __weak paddr_vmcoreinfo_note(void)
> >>  {
> >> -  return __pa((unsigned long)(char *)_note);
> >> +  return __pa_symbol((unsigned long)(char *)_note);
> >>  }
> >>  
> >>  static int __init crash_save_vmcoreinfo_init(void)
> >> -- 
> >> 2.7.4
> >> 
> >> 
> >> ___
> >> kexec mailing list
> >> kexec@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/kexec
> >
> > Thanks
> > Dave

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCHv4 07/10] kexec: Switch to __pa_symbol

[Eric W. Biederman]

Dave Young  writes:

> Hi, Laura
> On 11/29/16 at 10:55am, Laura Abbott wrote:
>> 
>> __pa_symbol is the correct api to get the physical address of kernel
>> symbols. Switch to it to allow for better debug checking.
>> 
>
> I assume __pa_symbol is faster than __pa, but it still need some testing
> on all arches which support kexec.
>
> But seems long long ago there is a commit e3ebadd95cb in the commit log
> I see below from:
> "we should deprecate __pa_symbol(), and preferably __pa() too - and
>  just use "virt_to_phys()" instead, which is is more readable and has
>  nicer semantics."
>
> But maybe in modern code __pa_symbol is prefered I may miss background.
> virt_to_phys still sounds more readable now for me though.

There has been a lot of history with the various definitions.
__pa_symbol used to be x86 specific.

Now what we have is that __pa_symbol is just __pa(RELOC_HIDE(x));

Now arguably that whole reloc hide thing should happen by architectures
having a non-inline version of __pa as was done in the commit you
mention.  But at this point there appears to be nothing wrong with
changing a __pa to a __pa_symbol it might make things a tad more
reliable depending on the implementation of __pa.

Acked-by: "Eric W. Biederman" 


Eric

>> Signed-off-by: Laura Abbott 
>> ---
>> Found during review of the kernel. Untested.
>> ---
>>  kernel/kexec_core.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>> index 5616755..e1b625e 100644
>> --- a/kernel/kexec_core.c
>> +++ b/kernel/kexec_core.c
>> @@ -1397,7 +1397,7 @@ void __weak arch_crash_save_vmcoreinfo(void)
>>  
>>  phys_addr_t __weak paddr_vmcoreinfo_note(void)
>>  {
>> -return __pa((unsigned long)(char *)_note);
>> +return __pa_symbol((unsigned long)(char *)_note);
>>  }
>>  
>>  static int __init crash_save_vmcoreinfo_init(void)
>> -- 
>> 2.7.4
>> 
>> 
>> ___
>> kexec mailing list
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>
> Thanks
> Dave

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCHv4 07/10] kexec: Switch to __pa_symbol

[Dave Young]

Hi, Laura
On 11/29/16 at 10:55am, Laura Abbott wrote:
> 
> __pa_symbol is the correct api to get the physical address of kernel
> symbols. Switch to it to allow for better debug checking.
> 

I assume __pa_symbol is faster than __pa, but it still need some testing
on all arches which support kexec.

But seems long long ago there is a commit e3ebadd95cb in the commit log
I see below from:
"we should deprecate __pa_symbol(), and preferably __pa() too - and
 just use "virt_to_phys()" instead, which is is more readable and has
 nicer semantics."

But maybe in modern code __pa_symbol is prefered I may miss background.
virt_to_phys still sounds more readable now for me though.

> Signed-off-by: Laura Abbott 
> ---
> Found during review of the kernel. Untested.
> ---
>  kernel/kexec_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 5616755..e1b625e 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -1397,7 +1397,7 @@ void __weak arch_crash_save_vmcoreinfo(void)
>  
>  phys_addr_t __weak paddr_vmcoreinfo_note(void)
>  {
> - return __pa((unsigned long)(char *)_note);
> + return __pa_symbol((unsigned long)(char *)_note);
>  }
>  
>  static int __init crash_save_vmcoreinfo_init(void)
> -- 
> 2.7.4
> 
> 
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Thanks
Dave

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] iommu/vt-d: Flush old iotlb for kdump when the device gets context mapped

[Xunlei Pang]

On 11/30/2016 at 10:26 PM, Joerg Roedel wrote:
> On Wed, Nov 30, 2016 at 06:23:34PM +0800, Baoquan He wrote:
>> OK, talked with Xunlei. The old cache could be entry with present bit
>> set.
> -EPARSE
>
> Anyway, what I was trying to say is, that the IOMMU TLB is tagged with
> domain-ids, and that there is also a context-cache which maps device-ids
> to domain-ids.
>
> If we update the context entry then we need to flush only the context
> entry, as it will point to a new domain-id then and future IOTLB lookups
> in the IOMMU will be using the new domain-id and do not match the old
> entries.

Hi Joerg,

Thanks for the explanation, and we still need to flush context cache using old 
domain-id, right?
How about the following update?

index 3965e73..624eac9 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2024,6 +2024,25 @@ static int domain_context_mapping_one(struct dmar_domain 
*domain,
if (context_present(context))
goto out_unlock;
 
+   /*
+* For kdump cases, old valid entries may be cached due to the
+* in-flight DMA and copied pgtable, but there is no unmapping
+* behaviour for them, thus we need an explicit cache flush for
+* the newly-mapped device. For kdump, at this point, the device
+* is supposed to finish reset at its driver probe stage, so no
+* in-flight DMA will exist, and we don't need to worry anymore
+* hereafter.
+*/
+   if (context_copied(context)) {
+   u16 did_old = context_domain_id(context);
+
+   if (did_old >= 0 && did_old < cap_ndoms(iommu->cap))
+   iommu->flush.flush_context(iommu, did_old,
+  (((u16)bus) << 8) | devfn,
+  DMA_CCMD_MASK_NOBIT,
+  DMA_CCMD_DEVICE_INVL);
+   }
+
pgd = domain->pgd;


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v28 9/9] Documentation: dt: chosen properties for arm64 kdump

[Rob Herring]

On Thu, Nov 24, 2016 at 05:14:13PM +, Catalin Marinas wrote:
> On Thu, Nov 24, 2016 at 06:59:44PM +0900, AKASHI Takahiro wrote:
> > From: James Morse 
> > 
> > Add documentation for
> > linux,crashkernel-base and crashkernel-size,
> > linux,usable-memory-range
> > linux,elfcorehdr
> > used by arm64 kdump to decribe the kdump reserved area, and
> > the elfcorehdr's location within it.
> > 
> > Signed-off-by: James Morse 
> > [takahiro.aka...@linaro.org: added "linux,crashkernel-base" and "-size" ]
> > Signed-off-by: AKASHI Takahiro 
> > Cc: devicet...@vger.kernel.org
> > Cc: Rob Herring 
> > Cc: Mark Rutland 
> 
> Rob, Mark, are you ok with this patch?

I'm leaving this one to Mark.

Rob

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] purgatory: Change default sha256 optimization to -O2

[Simon Horman]

On Mon, Nov 28, 2016 at 11:14:38AM +0530, Pratyush Anand wrote:
> On Thu, Nov 24, 2016 at 1:23 PM, Simon Horman  wrote:
> > On Wed, Nov 23, 2016 at 09:57:09AM -0800, Geoff Levand wrote:
> >> Change the default purgatory sha256 code optimization from -O0 to -O2, and 
> >> add a
> >> new arch specific makefile variable $(ARCH)_PURGATORY_SHA256_CFLAGS which 
> >> can
> >> over ride this default.  Set ia64_PURGATORY_SHA256_CFLAGS to -O0 to retain 
> >> the
> >> previous optimization level for ia64.
> >>
> >> The purgatory sha256 code needs the be built with -O0 for the  ia64
> >> architecture.  Currently this code is built with -O0 for all architectures,
> >> which slows down the calculations for architectures which could otherwise
> >> use -O2.
> >
> > Could you give an indication of the performance improvement you expect,
> > e.g. on arm64?
> >
> 
> It takes around 20 second to verify SHA in purgatory when vmlinuz
> image is around 13MB and initramfs is around 30M with -O2 enables.
> Otherwise, it takes more than 2 minutes.

Thanks.

This patch doesn't seem to apply against the master branch.
I'm wondering if you or Geoff could:

1. Rebase the patch
2. Include some text about the performance improvement.
   Something like what is above would be fine from my pov.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] iommu/vt-d: Flush old iotlb for kdump when the device gets context mapped

[Baoquan He]

On 11/30/16 at 05:03pm, Baoquan He wrote:
> On 11/30/16 at 04:15pm, Xunlei Pang wrote:
> > On 11/29/2016 at 10:35 PM, Joerg Roedel wrote:
> > > On Thu, Nov 17, 2016 at 10:47:28AM +0800, Xunlei Pang wrote:
> > >> As per the comment, the code here only needs to flush context caches
> > >> for the special domain 0 which is used to tag the
> > >> non-present/erroneous caches, seems we should flush the old domain id
> > >> of present entries for kdump according to the analysis, other than the
> > >> new-allocated domain id. Let me ponder more on this.
> > > Flushing the context entry only is fine. The old domain-id will not be
> > > re-used anyway, so there is no point in reading it out of the context
> > > table and flush it.
> > 
> > Do you mean to flush the context entry using the new-allocated domain id?
> > 
> > Yes, old domain-id will not be re-used as they were reserved when copy, but
> > may still be cached by in-flight DMA access.
> 
> Joerg is saying you have flushed context entry which is the ingress,
> new DMA can't get an entrance to hit the iotlb accordingly. Since you
> have bolted the ingress gate. I guess

And please code comment at the bottom of iommu_init_domains(), you can
see domain 0 is a special domain id.


~
/*
 * If Caching mode is set, then invalid translations are tagged
 * with domain-id 0, hence we need to pre-allocate it. We also
 * use domain-id 0 as a marker for non-allocated domain-id, so
 * make sure it is not used for a real domain.
 */
set_bit(0, iommu->domain_ids);
~~

And in vt-d spec, at the end of section 6.2.2 and the following
sections, you can see domain 0 is used to tag the cached entry.

I guess that's why it works with only domain 0 specified. The simple
thing to verify that is you specify another did, E.g 100 for your
flushing, see if it still works.


So, if it's just as above, v1 should be good enough.

Besides, you should use translation_pre_enabled(). If 1st kernel add
intel_iommu=off, no need to do this.

Thanks
Baoquan
> 
> > 
> > Here is what the things seem to be from my understanding, and why I want to
> > flush using the old domain id:
> > 1) In kdump mode, old tables are copied, and all the iommu caches are 
> > flushed.
> > 2) There comes some in-flight DMA before the device's new context is mapped,
> > so translation caches(context, iotlb, etc) are created tagging old 
> > domain-id
> > in the iommu hardware.
> > 3) At the driver probe stage, the device is reset , and no in-flight DMA 
> > will exist.
> > Here I assumed that the device reset won't flush the old caches in the 
> > iommu
> > hardware related to this device. I haven't found any relevant 
> > specification, please
> > correct me if I am wrong.
> > 4) Then new context is setup, and new DMA is initiated, hit old cache that 
> > was
> > created in 2) as currently there's no such flush action, so DMAR fault 
> > happens.
> > 
> > I already posted v2 to flush context/iotlb using the old domain-id:
> > https://lkml.org/lkml/2016/11/18/514
> > 
> > Regards,
> > Xunlei
> > 
> > >
> > > Also, please add a Fixes-tag when you re-post this patch.
> > >
> > >
> > >   Joerg
> > >
> > 
> > 
> > ___
> > kexec mailing list
> > kexec@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] iommu/vt-d: Flush old iotlb for kdump when the device gets context mapped

[Baoquan He]

On 11/30/16 at 04:15pm, Xunlei Pang wrote:
> On 11/29/2016 at 10:35 PM, Joerg Roedel wrote:
> > On Thu, Nov 17, 2016 at 10:47:28AM +0800, Xunlei Pang wrote:
> >> As per the comment, the code here only needs to flush context caches
> >> for the special domain 0 which is used to tag the
> >> non-present/erroneous caches, seems we should flush the old domain id
> >> of present entries for kdump according to the analysis, other than the
> >> new-allocated domain id. Let me ponder more on this.
> > Flushing the context entry only is fine. The old domain-id will not be
> > re-used anyway, so there is no point in reading it out of the context
> > table and flush it.
> 
> Do you mean to flush the context entry using the new-allocated domain id?
> 
> Yes, old domain-id will not be re-used as they were reserved when copy, but
> may still be cached by in-flight DMA access.

Joerg is saying you have flushed context entry which is the ingress,
new DMA can't get an entrance to hit the iotlb accordingly. Since you
have bolted the ingress gate. I guess

> 
> Here is what the things seem to be from my understanding, and why I want to
> flush using the old domain id:
> 1) In kdump mode, old tables are copied, and all the iommu caches are flushed.
> 2) There comes some in-flight DMA before the device's new context is mapped,
> so translation caches(context, iotlb, etc) are created tagging old 
> domain-id
> in the iommu hardware.
> 3) At the driver probe stage, the device is reset , and no in-flight DMA will 
> exist.
> Here I assumed that the device reset won't flush the old caches in the 
> iommu
> hardware related to this device. I haven't found any relevant 
> specification, please
> correct me if I am wrong.
> 4) Then new context is setup, and new DMA is initiated, hit old cache that was
> created in 2) as currently there's no such flush action, so DMAR fault 
> happens.
> 
> I already posted v2 to flush context/iotlb using the old domain-id:
> https://lkml.org/lkml/2016/11/18/514
> 
> Regards,
> Xunlei
> 
> >
> > Also, please add a Fixes-tag when you re-post this patch.
> >
> >
> > Joerg
> >
> 
> 
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] iommu/vt-d: Flush old iotlb for kdump when the device gets context mapped

[Xunlei Pang]

On 11/29/2016 at 10:35 PM, Joerg Roedel wrote:
> On Thu, Nov 17, 2016 at 10:47:28AM +0800, Xunlei Pang wrote:
>> As per the comment, the code here only needs to flush context caches
>> for the special domain 0 which is used to tag the
>> non-present/erroneous caches, seems we should flush the old domain id
>> of present entries for kdump according to the analysis, other than the
>> new-allocated domain id. Let me ponder more on this.
> Flushing the context entry only is fine. The old domain-id will not be
> re-used anyway, so there is no point in reading it out of the context
> table and flush it.

Do you mean to flush the context entry using the new-allocated domain id?

Yes, old domain-id will not be re-used as they were reserved when copy, but
may still be cached by in-flight DMA access.

Here is what the things seem to be from my understanding, and why I want to
flush using the old domain id:
1) In kdump mode, old tables are copied, and all the iommu caches are flushed.
2) There comes some in-flight DMA before the device's new context is mapped,
so translation caches(context, iotlb, etc) are created tagging old domain-id
in the iommu hardware.
3) At the driver probe stage, the device is reset , and no in-flight DMA will 
exist.
Here I assumed that the device reset won't flush the old caches in the iommu
hardware related to this device. I haven't found any relevant 
specification, please
correct me if I am wrong.
4) Then new context is setup, and new DMA is initiated, hit old cache that was
created in 2) as currently there's no such flush action, so DMAR fault 
happens.

I already posted v2 to flush context/iotlb using the old domain-id:
https://lkml.org/lkml/2016/11/18/514

Regards,
Xunlei

>
> Also, please add a Fixes-tag when you re-post this patch.
>
>
>   Joerg
>


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCHv4 00/10] CONFIG_DEBUG_VIRTUAL for arm64

[Laura Abbott]

Hi,

This is v4 of the series to add CONFIG_DEBUG_VIRTUAL for arm64. This mostly
expanded on __pa_symbol conversion with a few new sites found. There's also
some reworking done to avoid calling __va too early. __va relies on having
memstart_addr set so very early code in early_fixmap_init and early KASAN
initialization can't just call __va(__Ipa_symbol(...)) to get the linear map
alias. I found this while testing with DEBUG_VM.

All of this could use probably use more testing under more configurations.
KVM, Xen, kexec, hibernate should all be tested.

Thanks,
Laura

Laura Abbott (10):
  lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
  mm/cma: Cleanup highmem check
  arm64: Move some macros under #ifndef __ASSEMBLY__
  arm64: Add cast for virt_to_pfn
  arm64: Use __pa_symbol for kernel symbols
  xen: Switch to using __pa_symbol
  kexec: Switch to __pa_symbol
  mm/kasan: Switch to using __pa_symbol and lm_alias
  mm/usercopy: Switch to using lm_alias
  arm64: Add support for CONFIG_DEBUG_VIRTUAL

 arch/arm64/Kconfig|  1 +
 arch/arm64/include/asm/kvm_mmu.h  |  4 +-
 arch/arm64/include/asm/memory.h   | 67 ++-
 arch/arm64/include/asm/mmu_context.h  |  6 +--
 arch/arm64/include/asm/pgtable.h  |  2 +-
 arch/arm64/kernel/acpi_parking_protocol.c |  2 +-
 arch/arm64/kernel/cpu-reset.h |  2 +-
 arch/arm64/kernel/cpufeature.c|  2 +-
 arch/arm64/kernel/hibernate.c | 13 +++---
 arch/arm64/kernel/insn.c  |  2 +-
 arch/arm64/kernel/psci.c  |  2 +-
 arch/arm64/kernel/setup.c |  8 ++--
 arch/arm64/kernel/smp_spin_table.c|  2 +-
 arch/arm64/kernel/vdso.c  |  4 +-
 arch/arm64/mm/Makefile|  2 +
 arch/arm64/mm/init.c  | 11 ++---
 arch/arm64/mm/kasan_init.c| 21 ++
 arch/arm64/mm/mmu.c   | 32 +--
 arch/arm64/mm/physaddr.c  | 28 +
 arch/x86/Kconfig  |  1 +
 drivers/firmware/psci.c   |  2 +-
 drivers/xen/xenbus/xenbus_dev_backend.c   |  2 +-
 drivers/xen/xenfs/xenstored.c |  2 +-
 include/linux/mm.h|  4 ++
 kernel/kexec_core.c   |  2 +-
 lib/Kconfig.debug |  5 ++-
 mm/cma.c  | 15 +++
 mm/kasan/kasan_init.c | 12 +++---
 mm/usercopy.c |  4 +-
 29 files changed, 167 insertions(+), 93 deletions(-)
 create mode 100644 arch/arm64/mm/physaddr.c

-- 
2.7.4


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec