Re: [Xen-devel] New IOREQ type -- IOREQ_TYPE_VMWARE_PORT

[Don Slutz <dslutz@xxxxxxxxxxx>]

On 01/30/15 05:23, Paul Durrant wrote:
>> -----Original Message-----
>> From: Don Slutz [mailto:dslutz@xxxxxxxxxxx]
>> Sent: 29 January 2015 19:41
>> To: Paul Durrant; Don Slutz; qemu-devel@xxxxxxxxxx; Stefano Stabellini
>> Cc: Peter Maydell; Olaf Hering; Alexey Kardashevskiy; Stefan Weil; Michael
>> Tokarev; Alexander Graf; Gerd Hoffmann; Stefan Hajnoczi; Paolo Bonzini;
>> xen-devel
>> Subject: New IOREQ type -- IOREQ_TYPE_VMWARE_PORT
>>
>>>> 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.
>>

This does look very doable.  The only issue I see is that it requires
a QEMU change in order to work.  This would prevent Xen 4.6 from using
QEMU 2.2.0 and vmport (vmware-tools, vmware-mouse).

What makes sense to me is to "invert it"  I.E. the default is to send
IOREQ_TYPE_VMWARE_PORT via io_range, and an ioreq server can say stop
sending them.

The reason this is safe so far is that IOREQ_TYPE_VMWARE_PORT can only
be sent if vmport is configured on.  And in that case QEMU will be
started with vmport=on which will cause all QEMUs that do not support
IOREQ_TYPE_VMWARE_PORT to crash.




>>
>>>> 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?
>>
> 
> hvm_do_resume() walks the ioreq server list looking at the IOREQ state in the 
> shared page of each server in turn. If no IOREQ was sent to that server then 
> then state will be IOREQ_NONE and hvm_wait_for_io() will return 1 immediately 
> so the outer loop in hvm_do_resume() will move on to the next server. If a 
> state of IOREQ_READY or IOREQ_INPROCESS is found then the vcpu blocks on the 
> relevant event channel until the state transitions to IORESP_READY. The IOREQ 
> is then completed and the loop moves on to the next server.
> Normally an IOREQ would only be directed at one server and indeed IOREQs that 
> are issued for emulation requests (i.e. when io_state != HVMIO_none) fall 
> into this category but there is one case of a broadcast IOREQ, which is the 
> INVALIDATE IOREQ (sent to tell emulators to invalidate any mappings of guest 
> memory they may have cached) and that is why hvm_do_resume() has to iterate 
> over all servers.
> 
> Does that make sense?
> 

Thanks for the clear info.  It does make sense.

   -Don Slutz

>   Paul
> 
>>    -Don Slutz
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel