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

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

[Juergen Gross]

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

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

[Boris Ostrovsky]

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 */

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

[Boris Ostrovsky]

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 */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Jan Beulich]

>>> 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

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

[Jan Beulich]

>>> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Juergen Gross]

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

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

[Juergen Gross]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Juergen Gross]

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

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

[Juergen Gross]

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Juergen Gross]

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel