From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 0C91A2C008E for ; Fri, 1 Feb 2013 14:06:33 +1100 (EST) Received: by mail-da0-f44.google.com with SMTP id z20so1548781dae.3 for ; Thu, 31 Jan 2013 19:06:31 -0800 (PST) Message-ID: <1359687985.1303.15.camel@kernel> Subject: Re: [PATCH v6 00/15] memory-hotplug: hot-remove physical memory From: Simon Jeons To: Tang Chen Date: Thu, 31 Jan 2013 21:06:25 -0600 In-Reply-To: <510B2B8A.7040407@cn.fujitsu.com> References: <1357723959-5416-1-git-send-email-tangchen@cn.fujitsu.com> <1359463973.1624.15.camel@kernel> <5108F2B3.3090506@cn.fujitsu.com> <1359595344.1557.13.camel@kernel> <5109E59F.5080104@cn.fujitsu.com> <1359613162.1587.0.camel@kernel> <510A18FA.2010107@cn.fujitsu.com> <1359622123.1391.19.camel@kernel> <510A3CE6.202@cn.fujitsu.com> <1359628705.2048.5.camel@kernel> <510B1B4B.5080207@huawei.com> <1359682576.3574.1.camel@kernel> <510B20F9.10408@cn.fujitsu.com> <1359685040.1303.6.camel@kernel> <510B2B8A.7040407@cn.fujitsu.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, linux-mm@kvack.org, paulus@samba.org, hpa@zytor.com, sparclinux@vger.kernel.org, cl@linux.com, linux-s390@vger.kernel.org, x86@kernel.org, linux-acpi@vger.kernel.org, isimatu.yasuaki@jp.fujitsu.com, linfeng@cn.fujitsu.com, mgorman@suse.de, kosaki.motohiro@jp.fujitsu.com, rientjes@google.com, len.brown@intel.com, wency@cn.fujitsu.com, cmetcalf@tilera.com, glommer@parallels.com, Jianguo Wu , yinghai@kernel.org, laijs@cn.fujitsu.com, linux-kernel@vger.kernel.org, minchan.kim@gmail.com, akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Tang, On Fri, 2013-02-01 at 10:42 +0800, Tang Chen wrote: I confuse! > Hi Simon, > > On 02/01/2013 10:17 AM, Simon Jeons wrote: > >> For example: > >> > >> 64TB, what ever > >> xxxTB, what ever > >> logic address space: |_____kernel_______|_________user_________________| > >> \ \ / / > >> \ /\ / > >> physical address space: |___\/__\/_____________| 4GB or > >> 8GB, what ever > >> ***** > > > > How much address space user process can have on x86_64? Also 8GB? > > Usually, we don't say that. > > 8GB is your physical memory, right ? > But kernel space and user space is the logic conception in OS. They are > in logic > address space. > > So both the kernel space and the user space can use all the physical memory. > But if the page is already in use by either of them, the other one > cannot use it. > For example, some pages are direct mapped to kernel, and is in use by > kernel, the > user space cannot map it. How can distinguish map and use? I mean how can confirm memory is used by kernel instead of map? > > > > >> > >> The ***** part physical is mapped to user space in the process' own > >> pagetable. > >> It is also direct mapped in kernel's pagetable. So the kernel can also > >> access it. :) > > > > But how to protect user process not modify kernel memory? > > This is the job of CPU. On intel cpus, user space code is running in > level 3, and > kernel space code is running in level 0. So the code in level 3 cannot > access the data > segment in level 0. 1) If user process and kenel map to same physical memory, user process will get SIGSEGV during #PF if access to this memory, but If user proces s will map to the same memory which kernel map? Why? It can't access it. 2) If two user processes map to same physical memory, what will happen if one process access the memory? > > Thanks. :)