[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <58DD3AF6020000780014ABAE@prv-mh.provo.novell.com>
Date: Thu, 30 Mar 2017 09:05:58 -0600
From: "Jan Beulich" <JBeulich@...e.com>
To: "Juergen Gross" <jgross@...e.com>
Cc: <xen-devel@...ts.xenproject.org>, <boris.ostrovsky@...cle.com>,
"Petr Tesarik" <PTesarik@...e.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen, kdump: handle pv domain in
paddr_vmcoreinfo_note()
>>> On 30.03.17 at 16:18, <jgross@...e.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
Powered by blists - more mailing lists