qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] New IOREQ type -- IOREQ_TYPE_VMWARE_PORT


From: Don Slutz
Subject: [Qemu-devel] New IOREQ type -- IOREQ_TYPE_VMWARE_PORT
Date: Thu, 29 Jan 2015 14:41:21 -0500
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

>> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]