From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 2/2] qemu-kvm: x86: Add support for VCPU event states Date: Sun, 15 Nov 2009 16:27:07 +0200 Message-ID: <4B000FBB.3000600@redhat.com> References: <4AFB5123.7000301@web.de> <4AFB515D.1030202@web.de> <4B00087C.4060007@redhat.com> <4B000E71.3020901@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm , Juan Quintela To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:15247 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753135AbZKOO1F (ORCPT ); Sun, 15 Nov 2009 09:27:05 -0500 In-Reply-To: <4B000E71.3020901@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 11/15/2009 04:21 PM, Jan Kiszka wrote: > Avi Kivity wrote: > >> On 11/12/2009 02:05 AM, Jan Kiszka wrote: >> >>> This patch extends the qemu-kvm state sync logic with support for >>> KVM_GET/SET_VCPU_EVENTS, giving access to yet missing exception, >>> interrupt and NMI states. >>> >>> diff --git a/target-i386/machine.c b/target-i386/machine.c >>> index 6bd447f..1eda7c5 100644 >>> --- a/target-i386/machine.c >>> +++ b/target-i386/machine.c >>> @@ -452,6 +452,11 @@ static const VMStateDescription vmstate_cpu = { >>> VMSTATE_INT32_V(interrupt_injected, CPUState, 9), >>> VMSTATE_UINT32_V(mp_state, CPUState, 9), >>> VMSTATE_UINT64_V(tsc, CPUState, 9), >>> + VMSTATE_UINT8_V(soft_interrupt, CPUState, 11), >>> + VMSTATE_UINT8_V(nmi_injected, CPUState, 11), >>> + VMSTATE_UINT8_V(nmi_pending, CPUState, 11), >>> + VMSTATE_UINT8_V(has_error_code, CPUState, 11), >>> + VMSTATE_UINT32_V(sipi_vector, CPUState, 11), >>> /* MCE */ >>> VMSTATE_UINT64_V(mcg_cap, CPUState, 10), >>> VMSTATE_UINT64_V(mcg_status, CPUState, 10), >>> >>> >>> >> Is there a reason why you add 11 between 9 and 10? We'll probably see >> another 11 when someone else adds the next state. >> >> > Logical grouping ("/* KVM-related states */"). These aren't kvm-related, just not implemented in tcg yet. Nothing kvmish about them - it's all architectural state. > If anyone once tries to > add non-KVM stuff here just because it's version 12, it should be > rejected. I don't think you have to sort VMSTATE entries by their > version number. Am I right, Juan? > I'm worried about something else - someone looking at the end, seeing version 10, and appending new state with version 11. -- error compiling committee.c: too many arguments to function