linux-kernel - Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure

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: <54E46CB1.5010702@suse.com>
Date:	Wed, 18 Feb 2015 11:42:57 +0100
From:	Juergen Gross <jgross@...e.com>
To:	David Vrabel <david.vrabel@...rix.com>,
	linux-kernel@...r.kernel.org, xen-devel@...ts.xensource.com,
	konrad.wilk@...cle.com, boris.ostrovsky@...cle.com
Subject: Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared
 info structure

On 02/18/2015 11:32 AM, David Vrabel wrote:
> On 18/02/15 06:51, Juergen Gross wrote:
>> The linear p2m list should be anchored in the shared info structure
>
> I'm not really sure what you mean by "anchored".

Bad wording? What about:

The virtual address of the linear p2m list should be stored in the
shared info structure.

>
>> read by the Xen tools to be able to support 64 bit pv-domains larger
>> than 512 MB. Additionally the linear p2m list interface includes a
>> generation count which is changed prior to and after each mapping
>> change of the p2m list. Reading the generation count the Xen tools can
>> detect changes of the mappings and re-read the p2m list eventually.
> [...]
>> --- a/arch/x86/xen/p2m.c
>> +++ b/arch/x86/xen/p2m.c
>> @@ -256,6 +256,10 @@ void xen_setup_mfn_list_list(void)
>>   	HYPERVISOR_shared_info->arch.pfn_to_mfn_frame_list_list =
>>   		virt_to_mfn(p2m_top_mfn);
>>   	HYPERVISOR_shared_info->arch.max_pfn = xen_max_p2m_pfn;
>> +	HYPERVISOR_shared_info->arch.p2m_generation = 0;
>> +	HYPERVISOR_shared_info->arch.p2m_vaddr = (unsigned long)xen_p2m_addr;
>> +	HYPERVISOR_shared_info->arch.p2m_cr3 =
>> +		xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
>>   }
>>
>>   /* Set up p2m_top to point to the domain-builder provided p2m pages */
>> @@ -469,8 +473,10 @@ static pte_t *alloc_p2m_pmd(unsigned long addr, pte_t *pte_pg)
>>
>>   		ptechk = lookup_address(vaddr, &level);
>>   		if (ptechk == pte_pg) {
>> +			HYPERVISOR_shared_info->arch.p2m_generation++;
>>   			set_pmd(pmdp,
>>   				__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
>> +			HYPERVISOR_shared_info->arch.p2m_generation++;
>
> Do these increments of p2m_generation need to be atomic?

Hmm, they are done under lock. I don't think the compiler is allowed to
reorder the writes to p2m_generation across set_pmd().


Juergen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/