lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ