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