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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

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

  Paul

>    -Don Slutz


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