From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy Date: Wed, 17 Feb 2016 17:39:23 -0500 Message-ID: <56C4F69B.4020705@oracle.com> References: <1454733014-15237-1-git-send-email-mcgrof@kernel.org> <1454733014-15237-4-git-send-email-mcgrof@kernel.org> <20160206085930.GF25240@wotan.suse.de> <56B8B4D8.7050208@oracle.com> <20160209070629.GK25240@wotan.suse.de> <20160217204954.GO2023@pd.tnic> <56C4E474.2070206@oracle.com> <20160217220304.GP2023@pd.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andy Lutomirski , Borislav Petkov Cc: X86 ML , david.e.box@intel.com, Andrey Ryabinin , Lv Zheng , Jan Beulich , "H. Peter Anvin" , qiuxishi@huawei.com, Mauro Carvalho Chehab , Xen Devel , Joerg Roedel , "Rafael J. Wysocki" , Robert Moore , Ingo Molnar , Andrey Ryabinin , Rusty Russell , Thomas Gleixner , Michael Brown , Juergen Gross , Andrew Cooper , "linux-kernel@vger.kernel.org" , "Luis R. Rodriguez" , David Vrabel , long.wanglong@huawei.com, Fengguang Wu List-Id: xen-devel@lists.xenproject.org On 02/17/2016 05:18 PM, Andy Lutomirski wrote: > On Wed, Feb 17, 2016 at 2:03 PM, Borislav Petkov wrote: >> On Wed, Feb 17, 2016 at 04:21:56PM -0500, Boris Ostrovsky wrote: >>> That's exactly the point: if something is mapped it's an error for a >>> non-PV kernel. >> How would something be mapped there? __PAGE_OFFSET is >> 0xffff880000000000. >> >> Or are you thinking about some insanely b0rked kernel code mapping stuff >> in there? >> >>> By removing paravirt_enabled() we may miss those errors. Worse, I think we >>> may even crash while doing pagetable walk (although it's probably better to >>> crash here than to use an unexpected translation in real code somewhere) >> Well, if this is the only site which keeps paravirt_enabled() from being >> buried, we need to think about a better way to detect a hypervisor. >> Maybe we should look at x86_hyper, use CPUID(0x4...) or something else. >> >> What's your preference? > I'm confused. Isn't it the other way around? That is, checking for > the hypervisor range on all systems should be safer, right? Or am I > missing something? Hmm. I think you are right --- I was following wrong branch of the 'if' statement. We are always going straight to note_page(). Then yes, we should be able to remove paravirt_enabled(). Sorry for the noise. -boris