Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1613115 > unrolled thread

[PATCH] xen,kdump: handle pv domain in paddr_vmcoreinfo_note()

Back to article view | Back to linux.kernel

Contents

  [PATCH] xen,kdump: handle pv domain in paddr_vmcoreinfo_note() Juergen Gross <jgross@suse.com> - 2017-03-30 16:30 +0200
    Re: [PATCH] xen,kdump: handle pv domain in paddr_vmcoreinfo_note() Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-03-30 17:00 +0200
      Re: [PATCH] xen,kdump: handle pv domain in paddr_vmcoreinfo_note() Juergen Gross <jgross@suse.com> - 2017-03-31 10:10 +0200
    Re: [Xen-devel] [PATCH] xen, kdump: handle pv domain in  paddr_vmcoreinfo_note() "Jan Beulich" <JBeulich@suse.com> - 2017-03-30 17:10 +0200
    Re: [Xen-devel] [PATCH] xen, kdump: handle pv domain in  paddr_vmcoreinfo_note() Juergen Gross <jgross@suse.com> - 2017-03-31 10:10 +0200

#1613115 — [PATCH] xen,kdump: handle pv domain in paddr_vmcoreinfo_note()

For kdump to work correctly it needs the physical address of
vmcoreinfo_note. When running as dom0 this means the virtual address
has to be translated to the related machine address.

paddr_vmcoreinfo_note() is meant to do the translation via __pa() only,
but being attributed "weak" it can be replaced easily in Xen case.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
This patch needs to be rebased on top of Vitaly's series to split
pv- and hvm-code. I'll do this as soon as his series is in the Xen
tree in its final form.
---
 arch/x86/xen/mmu.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 37cb5aa..0e2b8d7 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -49,6 +49,9 @@
 #include <linux/memblock.h>
 #include <linux/seq_file.h>
 #include <linux/crash_dump.h>
+#ifdef CONFIG_KEXEC_CORE
+#include <linux/kexec.h>
+#endif
 
 #include <trace/events/xen.h>
 
@@ -2903,3 +2906,13 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
 	return -EINVAL;
 }
 EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
+
+#ifdef CONFIG_KEXEC_CORE
+phys_addr_t paddr_vmcoreinfo_note(void)
+{
+	if (xen_pv_domain())
+		return virt_to_machine(&vmcoreinfo_note).maddr;
+	else
+		return __pa((unsigned long)(char *)&vmcoreinfo_note);
+}
+#endif /* CONFIG_KEXEC_CORE */
-- 
2.10.2

[toc] | [next] | [standalone]

#1613134

On 03/30/2017 10:18 AM, Juergen Gross wrote:
> For kdump to work correctly it needs the physical address of
> vmcoreinfo_note. When running as dom0 this means the virtual address
> has to be translated to the related machine address.
>
> paddr_vmcoreinfo_note() is meant to do the translation via __pa() only,
> but being attributed "weak" it can be replaced easily in Xen case.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> This patch needs to be rebased on top of Vitaly's series to split
> pv- and hvm-code. I'll do this as soon as his series is in the Xen
> tree in its final form.
> ---
>  arch/x86/xen/mmu.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 37cb5aa..0e2b8d7 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -49,6 +49,9 @@
>  #include <linux/memblock.h>
>  #include <linux/seq_file.h>
>  #include <linux/crash_dump.h>
> +#ifdef CONFIG_KEXEC_CORE
> +#include <linux/kexec.h>
> +#endif
>  
>  #include <trace/events/xen.h>
>  
> @@ -2903,3 +2906,13 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
>  	return -EINVAL;
>  }
>  EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
> +
> +#ifdef CONFIG_KEXEC_CORE
> +phys_addr_t paddr_vmcoreinfo_note(void)
> +{
> +	if (xen_pv_domain())
> +		return virt_to_machine(&vmcoreinfo_note).maddr;
> +	else
> +		return __pa((unsigned long)(char *)&vmcoreinfo_note);

Why not __pa_symbol(), just like in the weak version?

-boris

> +}
> +#endif /* CONFIG_KEXEC_CORE */

[toc] | [prev] | [next] | [standalone]

#1613718

On 30/03/17 16:51, Boris Ostrovsky wrote:
> On 03/30/2017 10:18 AM, Juergen Gross wrote:
>> For kdump to work correctly it needs the physical address of
>> vmcoreinfo_note. When running as dom0 this means the virtual address
>> has to be translated to the related machine address.
>>
>> paddr_vmcoreinfo_note() is meant to do the translation via __pa() only,
>> but being attributed "weak" it can be replaced easily in Xen case.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> This patch needs to be rebased on top of Vitaly's series to split
>> pv- and hvm-code. I'll do this as soon as his series is in the Xen
>> tree in its final form.
>> ---
>>  arch/x86/xen/mmu.c | 13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
>> index 37cb5aa..0e2b8d7 100644
>> --- a/arch/x86/xen/mmu.c
>> +++ b/arch/x86/xen/mmu.c
>> @@ -49,6 +49,9 @@
>>  #include <linux/memblock.h>
>>  #include <linux/seq_file.h>
>>  #include <linux/crash_dump.h>
>> +#ifdef CONFIG_KEXEC_CORE
>> +#include <linux/kexec.h>
>> +#endif
>>  
>>  #include <trace/events/xen.h>
>>  
>> @@ -2903,3 +2906,13 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
>>  	return -EINVAL;
>>  }
>>  EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
>> +
>> +#ifdef CONFIG_KEXEC_CORE
>> +phys_addr_t paddr_vmcoreinfo_note(void)
>> +{
>> +	if (xen_pv_domain())
>> +		return virt_to_machine(&vmcoreinfo_note).maddr;
>> +	else
>> +		return __pa((unsigned long)(char *)&vmcoreinfo_note);
> 
> Why not __pa_symbol(), just like in the weak version?

Hmm, you are right. This patch originated from a 4.4 based one.


Juergen

[toc] | [prev] | [next] | [standalone]

#1613148 — Re: [Xen-devel] [PATCH] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

>>> On 30.03.17 at 16:18, <jgross@suse.com> wrote:
> @@ -2903,3 +2906,13 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
>  	return -EINVAL;
>  }
>  EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
> +
> +#ifdef CONFIG_KEXEC_CORE
> +phys_addr_t paddr_vmcoreinfo_note(void)
> +{
> +	if (xen_pv_domain())
> +		return virt_to_machine(&vmcoreinfo_note).maddr;
> +	else
> +		return __pa((unsigned long)(char *)&vmcoreinfo_note);

I don't think you need the double cast here.

This being placed in x86 code is correct only as long as the
assumption is correct that no other architecture will allow for
PV guests. And this being placed in Xen code is correct only
as long as the assumption is true that no other hypervisors
will allow for PV guests.

Jan

[toc] | [prev] | [next] | [standalone]

#1613720 — Re: [Xen-devel] [PATCH] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

On 30/03/17 17:05, Jan Beulich wrote:
>>>> On 30.03.17 at 16:18, <jgross@suse.com> wrote:
>> @@ -2903,3 +2906,13 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
>>  	return -EINVAL;
>>  }
>>  EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
>> +
>> +#ifdef CONFIG_KEXEC_CORE
>> +phys_addr_t paddr_vmcoreinfo_note(void)
>> +{
>> +	if (xen_pv_domain())
>> +		return virt_to_machine(&vmcoreinfo_note).maddr;
>> +	else
>> +		return __pa((unsigned long)(char *)&vmcoreinfo_note);
> 
> I don't think you need the double cast here.
> 
> This being placed in x86 code is correct only as long as the
> assumption is correct that no other architecture will allow for
> PV guests. And this being placed in Xen code is correct only
> as long as the assumption is true that no other hypervisors
> will allow for PV guests.

With virt_to_machine() defined in arch/x86/include/asm/xen/page.h
I think changing any of those assumptions will require major work.


Juergen

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web