From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [V10 PATCH 23/23] PVH xen: introduce vmexit handler for PVH Date: Tue, 6 Aug 2013 17:37:11 -0700 Message-ID: <20130806173711.2cb6219c@mantra.us.oracle.com> References: <1374631171-15224-1-git-send-email-mukesh.rathor@oracle.com> <1374631171-15224-24-git-send-email-mukesh.rathor@oracle.com> <20130725162840.GD87903@ocelot.phlegethon.org> <20130725193057.434cd254@mantra.us.oracle.com> <20130726104519.GB99616@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130726104519.GB99616@ocelot.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: Xen-devel@lists.xensource.com, keir.xen@gmail.com List-Id: xen-devel@lists.xenproject.org On Fri, 26 Jul 2013 11:45:19 +0100 Tim Deegan wrote: > At 19:30 -0700 on 25 Jul (1374780657), Mukesh Rathor wrote: > > On Thu, 25 Jul 2013 17:28:40 +0100 > > Tim Deegan wrote: > > > > > At 18:59 -0700 on 23 Jul (1374605971), Mukesh Rathor wrote: > > > > +/* Just like HVM, PVH should be using "cpuid" from the kernel > > > > mode. */ +static int vmxit_invalid_op(struct cpu_user_regs > > > > *regs) +{ > > > > + if ( guest_kernel_mode(current, regs) > > > > || !emulate_forced_invalid_op(regs) ) > > > > + hvm_inject_hw_exception(TRAP_invalid_op, > > > > HVM_DELIVER_NO_ERROR_CODE); > > > > > > Was this discussed before? It seems harsh to stop kernel-mode > > > code from using the pv cpuid operation if it wants to. In > > > particular, what about loadable kernel modules? > > > > Yes, few times on the xen mailing list. The only PVH guest, linux > > as of now, the pv ops got rewired to use native cpuid, which is > > how hvm does it. > > Yes, but presumably you want to make it easy for other PV guests to > port to PVH too? True, but how would not allowing kernel mode emulation impede that? I fail to understand why a new kernel would wanna use xen signature emulation over just plain cpuid instruction? I can understand an application would want to be ported unmodified, so we need to support at least in the short term, but a PVH kernel would need to be modified anyways, so why create more work, right? > > So, couldn't come up with any real reason to support it. > > Seems like there's no reason not to -- wouldn't jus > definitiont removing the check for kernel-mode DTRT? .. Most likely, but there's lot of code in that path, and I'd feel more comfortable doing it after testing it. It'll be a small patch in future anyways :). I'll document it near XEN_CPUID definition for now. thanks, mukesh