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 <[email protected]>
---
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
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 <[email protected]>
> ---
> 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 */
>>> On 30.03.17 at 16:18, <[email protected]> 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
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 <[email protected]>
>> ---
>> 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