From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760690AbXIODFz (ORCPT ); Fri, 14 Sep 2007 23:05:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753109AbXIODFr (ORCPT ); Fri, 14 Sep 2007 23:05:47 -0400 Received: from ozlabs.org ([203.10.76.45]:39601 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754690AbXIODFr (ORCPT ); Fri, 14 Sep 2007 23:05:47 -0400 Subject: Re: [PATCH] Refactor hypercall infrastructure From: Rusty Russell To: Jeremy Fitzhardinge Cc: Anthony Liguori , kvm-devel@lists.sourceforge.net, Avi Kivity , Ingo Molnar , Dor Laor , linux-kernel@vger.kernel.org In-Reply-To: <46EAF4C6.8090903@goop.org> References: <11897991353793-git-send-email-aliguori@us.ibm.com> <46EAF4C6.8090903@goop.org> Content-Type: text/plain Date: Sat, 15 Sep 2007 12:35:02 +1000 Message-Id: <1189823702.7262.68.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2007-09-14 at 13:53 -0700, Jeremy Fitzhardinge wrote: > Anthony Liguori wrote: > > This patch refactors the current hypercall infrastructure to better support live > > migration and SMP. It eliminates the hypercall page by trapping the UD > > exception that would occur if you used the wrong hypercall instruction for the > > underlying architecture and replacing it with the right one lazily. > > > > I guess it would be pretty rude/unlikely for these opcodes to get reused > in other implementations... But couldn't you make the page trap > instead, rather than relying on an instruction fault? That's a pain for inline hypercalls tho. I was planning on moving lguest to this model (which is interesting, because AFAICT this insn will cause a #UD or #GP depending on whether VT is supported on this box so I have to look for both). Cheers, Rusty. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: [PATCH] Refactor hypercall infrastructure Date: Sat, 15 Sep 2007 12:35:02 +1000 Message-ID: <1189823702.7262.68.camel@localhost.localdomain> References: <11897991353793-git-send-email-aliguori@us.ibm.com> <46EAF4C6.8090903@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Avi Kivity To: Jeremy Fitzhardinge Return-path: In-Reply-To: <46EAF4C6.8090903-TSDbQ3PG+2Y@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org On Fri, 2007-09-14 at 13:53 -0700, Jeremy Fitzhardinge wrote: > Anthony Liguori wrote: > > This patch refactors the current hypercall infrastructure to better support live > > migration and SMP. It eliminates the hypercall page by trapping the UD > > exception that would occur if you used the wrong hypercall instruction for the > > underlying architecture and replacing it with the right one lazily. > > > > I guess it would be pretty rude/unlikely for these opcodes to get reused > in other implementations... But couldn't you make the page trap > instead, rather than relying on an instruction fault? That's a pain for inline hypercalls tho. I was planning on moving lguest to this model (which is interesting, because AFAICT this insn will cause a #UD or #GP depending on whether VT is supported on this box so I have to look for both). Cheers, Rusty. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/