From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:52719)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <dslutz@verizon.com>) id 1YGuyA-0003y5-0d
	for qemu-devel@nongnu.org; Thu, 29 Jan 2015 14:41:38 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <dslutz@verizon.com>) id 1YGuy6-0001Bj-RU
	for qemu-devel@nongnu.org; Thu, 29 Jan 2015 14:41:37 -0500
Received: from fldsmtpe04.verizon.com ([140.108.26.143]:1748)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <dslutz@verizon.com>) id 1YGuy6-0001BO-Ks
	for qemu-devel@nongnu.org; Thu, 29 Jan 2015 14:41:34 -0500
From: Don Slutz <dslutz@verizon.com>
Message-ID: <54CA8CE1.404@terremark.com>
Date: Thu, 29 Jan 2015 14:41:21 -0500
MIME-Version: 1.0
References: <1417776605-36309-1-git-send-email-paul.durrant@citrix.com>	<1417776605-36309-3-git-send-email-paul.durrant@citrix.com>
	<54C93934.2020707@terremark.com> <54C97947.5080908@terremark.com>
	<54C98586.3020509@terremark.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD0257DC103@AMSPEX01CL01.citrite.net>
	<54CA868A.6050407@terremark.com>
In-Reply-To: <54CA868A.6050407@terremark.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] New IOREQ type -- IOREQ_TYPE_VMWARE_PORT
List-Id: <qemu-devel.nongnu.org>
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>
To: Paul Durrant <Paul.Durrant@citrix.com>, Don Slutz <dslutz@verizon.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Stefano Stabellini <Stefano.Stabellini@citrix.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, Olaf Hering <olaf@aepfle.de>, Alexey Kardashevskiy <aik@ozlabs.ru>, Stefan Weil <sw@weilnetz.de>, Michael Tokarev <mjt@tls.msk.ru>, Alexander Graf <agraf@suse.de>, xen-devel <xen-devel@lists.xen.org>, Gerd Hoffmann <kraxel@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>

>> On 01/29/15 07:09, Paul Durrant wrote:
...
>> Given that IIRC you are using a new dedicated IOREQ type, I
>> think there needs to be something that allows an emulator to
>> register for this IOREQ type. How about adding a new type to
>> those defined for HVMOP_map_io_range_to_ioreq_server for your
>> case? (In your case the start and end values in the hypercall
>> would be meaningless but it could be used to steer
>> hvm_select_ioreq_server() into sending all emulation requests or
>> your new type to QEMU.
>>

This is an interesting idea.  Will need to spend more time on it.


>> Actually such a mechanism could be used
>> to steer IOREQ_TYPE_TIMEOFFSET requests as, with the new QEMU
>> patches, they are going nowhere. Upstream QEMU (as default) used
>> to ignore them anyway, which is why I didn't bother with such a
>> patch to Xen before but since you now need one maybe you could
>> add that too?
>>

I think it would not be that hard.  Will look into adding it.


Currently I do not see how hvm_do_resume() works with 2 ioreq servers.
It looks like to me that if a vpcu (like 0) needs to wait for the
2nd ioreq server, hvm_do_resume() will check the 1st ioreq server
and return as if the ioreq is done.  What am I missing?

   -Don Slutz