From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Date: Tue, 31 Aug 2010 06:28:30 +0000 Subject: Re: [PATCH 13/26] KVM: PPC: Add feature bitmap for magic page Message-Id: <4C7CA10E.1090505@redhat.com> List-Id: References: <1282053481-18787-1-git-send-email-agraf@suse.de> <1282053481-18787-14-git-send-email-agraf@suse.de> <4C715382.6050809@redhat.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexander Graf Cc: kvm-ppc@vger.kernel.org, linuxppc-dev , KVM list On 08/31/2010 03:56 AM, Alexander Graf wrote: > On 22.08.2010, at 18:42, Avi Kivity wrote: > >> On 08/17/2010 04:57 PM, Alexander Graf wrote: >>> We will soon add SR PV support to the shared page, so we need some >>> infrastructure that allows the guest to query for features KVM exports. >>> >>> This patch adds a second return value to the magic mapping that >>> indicated to the guest which features are available. >>> >> You need to make that feature controllable from userspace, to allow new->old save/restore. > Good one :). We're still missing too much stuff to even run without losing interrupts yet and you're thinking about new->old save/restore. Who'd want to migrate onto a system that's broken anyways? Besides - we're missing too many register values from the kernel side to even be able to perform a migration. > > I'm planning to add migration, probably after SMP. But that will be another CAP and anything before that won't be able to save/restore. I'm thinking stability and basic functionality and your running around adding features (or new archs, depending on mood). But I agree, this can wait until after SMP. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ozlabs.org (Postfix) with ESMTP id 21B3DB7134 for ; Tue, 31 Aug 2010 16:28:35 +1000 (EST) Message-ID: <4C7CA10E.1090505@redhat.com> Date: Tue, 31 Aug 2010 09:28:30 +0300 From: Avi Kivity MIME-Version: 1.0 To: Alexander Graf Subject: Re: [PATCH 13/26] KVM: PPC: Add feature bitmap for magic page References: <1282053481-18787-1-git-send-email-agraf@suse.de> <1282053481-18787-14-git-send-email-agraf@suse.de> <4C715382.6050809@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linuxppc-dev , KVM list , kvm-ppc@vger.kernel.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 08/31/2010 03:56 AM, Alexander Graf wrote: > On 22.08.2010, at 18:42, Avi Kivity wrote: > >> On 08/17/2010 04:57 PM, Alexander Graf wrote: >>> We will soon add SR PV support to the shared page, so we need some >>> infrastructure that allows the guest to query for features KVM exports. >>> >>> This patch adds a second return value to the magic mapping that >>> indicated to the guest which features are available. >>> >> You need to make that feature controllable from userspace, to allow new->old save/restore. > Good one :). We're still missing too much stuff to even run without losing interrupts yet and you're thinking about new->old save/restore. Who'd want to migrate onto a system that's broken anyways? Besides - we're missing too many register values from the kernel side to even be able to perform a migration. > > I'm planning to add migration, probably after SMP. But that will be another CAP and anything before that won't be able to save/restore. I'm thinking stability and basic functionality and your running around adding features (or new archs, depending on mood). But I agree, this can wait until after SMP. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 13/26] KVM: PPC: Add feature bitmap for magic page Date: Tue, 31 Aug 2010 09:28:30 +0300 Message-ID: <4C7CA10E.1090505@redhat.com> References: <1282053481-18787-1-git-send-email-agraf@suse.de> <1282053481-18787-14-git-send-email-agraf@suse.de> <4C715382.6050809@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-ppc@vger.kernel.org, linuxppc-dev , KVM list To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:32682 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756024Ab0HaG2j (ORCPT ); Tue, 31 Aug 2010 02:28:39 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 08/31/2010 03:56 AM, Alexander Graf wrote: > On 22.08.2010, at 18:42, Avi Kivity wrote: > >> On 08/17/2010 04:57 PM, Alexander Graf wrote: >>> We will soon add SR PV support to the shared page, so we need some >>> infrastructure that allows the guest to query for features KVM exports. >>> >>> This patch adds a second return value to the magic mapping that >>> indicated to the guest which features are available. >>> >> You need to make that feature controllable from userspace, to allow new->old save/restore. > Good one :). We're still missing too much stuff to even run without losing interrupts yet and you're thinking about new->old save/restore. Who'd want to migrate onto a system that's broken anyways? Besides - we're missing too many register values from the kernel side to even be able to perform a migration. > > I'm planning to add migration, probably after SMP. But that will be another CAP and anything before that won't be able to save/restore. I'm thinking stability and basic functionality and your running around adding features (or new archs, depending on mood). But I agree, this can wait until after SMP. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.