From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: Xen: Hybrid extension patchset for hypervisor Date: Wed, 16 Sep 2009 14:22:15 -0700 Message-ID: <4AB15707.20305@goop.org> References: <0B53E02A2965CE4F9ADB38B34501A3A1940C78A8@orsmsx505.amr.corp.intel.com> <4AB12C1F.9080502@goop.org> <1253135571.3896.4873.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1253135571.3896.4873.camel@localhost.localdomain> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: "Yang, Sheng" , "xen-devel@lists.xensource.com" , "Dong, Eddie" , Keir Fraser , "Nakajima, Jun" List-Id: xen-devel@lists.xenproject.org On 09/16/09 14:12, Ian Campbell wrote: >>> Based on our data, what we would want in PV 64-bit guests are, fundamentally: >>> - have the kernel run in ring 0 (so that it can regain the performance enhancements) >>> >>> >> That's no problem. PV kernels don't currently assume they're running in >> any particular ring, so they'd be happy to run in ring 0 if that's how >> they're started (if there are problems, I'd consider that a bug). We >> could then check for ring 0 and enable syscall/sysenter. >> > XENFEAT_supervisor_mode_kernel is supposed to enable this behaviour, > although it hasn't been actively used for several years and never in the > pvops kernel so you can bet it has bit-rotted... > That tends to have a slightly different meaning, viz "dom0 really *is* privileged and can do anything it feels like". It isn't necessary to have a specific feature/mechanism for "kernel happens to be in ring 0"; it can look at its own cs ring number. >> We could do that with minimal API/ABI changes by: >> >> * Providing an identity p2m table >> * Changing the hypercall page to make pte writes simple memory >> writes (no hypercalls); xen would still keep track of pinned pages >> and trap'n'emulate on them for back-compatibility (but fast-path >> with no validation). We could expose the presence of HAP via >> xen_features so that guests know they can avoid marking pagetables >> RO, etc. >> * Similarly, cr3 changes can be fast-pathed within the hypercall page. >> * Whatever else I've overlooked. >> > Some combination of XENFEAT_writable_page_tables > XENFEAT_writable_descriptor_tables and XENFEAT_auto_translated_physmap > might be of interest for this bit. Making use of XENFEAT_auto_translated_physmap would avoid the need for identity p2m/m2p tables, but I'm not sure whether it still works. I got close to completely removing all references to it at one point, but I think ia64 uses it?