From mboxrd@z Thu Jan  1 00:00:00 1970
From: Don Slutz <dslutz@verizon.com>
Subject: Re: [PATCH v2 1/1] xen-hvm.c: Add support for Xen
	access to vmport
Date: Fri, 03 Oct 2014 14:17:11 -0400
Message-ID: <542EE827.2040506@terremark.com>
References: <1412275867-6689-1-git-send-email-dslutz@verizon.com>
	<1412275867-6689-2-git-send-email-dslutz@verizon.com>
	<alpine.DEB.2.02.1410031047160.17038@kaball.uk.xensource.com>
	<542EA558.3010108@terremark.com>
	<alpine.DEB.2.02.1410031722200.17038@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <alpine.DEB.2.02.1410031722200.17038@kaball.uk.xensource.com>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Marcel Apfelbaum <marcel.a@redhat.com>, Markus Armbruster <armbru@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, qemu-devel@nongnu.org, Don Slutz <dslutz@verizon.com>, Alexander Graf <agraf@suse.de>, Anthony Liguori <aliguori@amazon.com>, =?ISO-8859-1?Q?Andreas_F=E4rber?= <afaerber@suse.de>
List-Id: xen-devel@lists.xenproject.org

On 10/03/14 12:23, Stefano Stabellini wrote:
> On Fri, 3 Oct 2014, Don Slutz wrote:
>> On 10/03/14 05:52, Stefano Stabellini wrote:
>>> On Thu, 2 Oct 2014, Don Slutz wrote:
>>>> This adds synchronisation of the 6 vcpu registers (only 32bits of
>>>> them) that vmport.c needs between Xen and QEMU.
>>>>
...
>>>>    }
>>>>    -static void handle_ioreq(ioreq_t *req)
>>>> +static void regs_to_cpu(XenIOState *state, vmware_ioreq_t *vmport_req)
>>>> +{
>>>> +    X86CPU *cpu;
>>>> +    CPUX86State *env;
>>>> +
>>>> +    if (!state->cpu_by_ioreq_id[0]) {
>>>> +        CPUState *cpu_state;
>>>> +
>>>> +        CPU_FOREACH(cpu_state) {
>>>> +            state->cpu_by_ioreq_id[cpu_state->cpu_index] = cpu_state;
>>>> +        }
>>>> +    }
>>> This is just the initialization, isn't it?
>>> It would be best to move it to an initialization function then.
>>>
>> A new initialization function would need to be added.  A new call to it would
>> need
>> to be added (not sure where the best place is).  Since the overhead here is
>> small I went with the less intrusive change.
> I'd prefer the initialization function if it is possible.
>
>
>

Ok, how does:


@@ -1023,6 +1028,11 @@ static void xen_main_loop_prepare(XenIOState *state)
                                                   state);

      if (evtchn_fd != -1) {
+        CPUState *cpu_state;
+
+        CPU_FOREACH(cpu_state) {
+            state->cpu_by_ioreq_id[cpu_state->cpu_index] = cpu_state;
+        }
          qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, state);
      }
  }

Look?

    -Don Slutz