Re: [Xen-devel] [PATCH] x86/hvm: don't rely on shared ioreq state for completion handling

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Fri, 2015-07-31 at 16:53 +0100, Andrew Cooper wrote:
> On 31/07/15 16:34, Paul Durrant wrote:
> > Both hvm_io_pending() and hvm_wait_for_io() use the shared (with 
> > emulator)
> > ioreq structure to determined whether there is a pending I/O. The 
> > latter will
> > misbehave if the shared state is driven to STATE_IOREQ_NONE by the 
> > emulator,
> > or when the shared ioreq page is cleared for re-insertion into the 
> > guest
> > P2M when the ioreq server is disabled (STATE_IOREQ_NONE == 0) because 
> > it
> > will terminate its wait without calling hvm_io_assist() to adjust Xen's
> > internal I/O emulation state. This may then lead to an io completion
> > handler finding incorrect internal emulation state and calling
> > domain_crash().
> > 
> > This patch fixes the problem by adding a pending flag to the ioreq 
> > server's
> > per-vcpu structure which cannot be directly manipulated by the emulator
> > and thus can be used to determine whether an I/O is actually pending 
> > for
> > that vcpu on that ioreq server. If an I/O is pending and the shared 
> > state
> > is seen to go to STATE_IOREQ_NONE then it can be treated as an abnormal
> > completion of emulation (hence the data placed in the shared structure
> > is not used) and the internal state is adjusted as for a normal 
> > completion.
> > Thus, when a completion handler subsequently runs, the internal state 
> > is as
> > expected and domain_crash() will not be called.
> > 
> > Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> > Reported-by: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
> > Tested-by: Roger Pau Monnà <roger.pau@xxxxxxxxxx>
> > Cc: Keir Fraser <keir@xxxxxxx>
> > Cc: Jan Beulich <jbeulich@xxxxxxxx>
> > Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> 
> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Applied, thanks.


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