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

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

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.