Re: [Xen-devel] [PATCH v4 16/17] x86/hvm: always re-emulate I/O from a buffer

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.06.15 at 12:32, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 25 June 2015 10:58
>> To: Paul Durrant
>> Cc: Andrew Cooper; xen-devel@xxxxxxxxxxxxxxxxxxxx; Keir (Xen.org)
>> Subject: Re: [PATCH v4 16/17] x86/hvm: always re-emulate I/O from a buffer
>> 
>> >>> On 24.06.15 at 13:24, <paul.durrant@xxxxxxxxxx> wrote:
>> > If memory mapped I/O is 'chunked' then the I/O must be re-emulated,
>> > otherwise only the first chunk will be processed. This patch makes
>> > sure all I/O from a buffer is re-emulated regardless of whether it
>> > is a read or a write.
>> 
>> I'm not sure I understand this: Isn't the reason for treating reads
>> and writes differently due to the fact that MMIO reads may have
>> side effects, and hence can't be re-issued (whereas writes are
>> always the last thing an instruction does, and hence can't hold up
>> retiring of it, and hence don't need retrying)?
> 
> Read were always re-issued, which is why handle_mmio() is called in 
> hvm_io_assit(). If the underlying MMIO is deferred to QEMU then this is the 
> only way for Xen to pick up the result. This patch adds completion for 
> writes.
> If the I/O has been broken down in the underlying hvmemul_write() and a 
> 'chunk' deferred to QEMU then there is actually need to re-emulate otherwise 
> any remaining chunks will not be handled.
> 
>> 
>> Furthermore, doesn't "only the first chunk" get represented correctly
>> already by informing the caller that only a single iteration of a
>> repeated instruction was done, such that further repeats will get
>> carried out anyway (resulting in another, fresh cycle through the
>> emulator)?
>> 
> 
> No, because we're talking about 'chunks' here and not 'reps'. If a single 
> non-rep I/O is broken down into, say, two chunks then we:
> 
> - Issue the I/O for the first chunk to QEMU
> - Say we did nothing by returning RETRY
> - Re-issue the emulation from hvm_io_assist()
> - Pick up the result of the first chunk from the ioreq, add it to the cache, 
> and issue the second chunk to QEMU
> - Say we did nothing by returning RETRY
> - Re-issue the emulation from hvm_io_assist()
> - Pick up the result of the first chunk from the cache and pick up the result 
> of the second chunk from the ioreq
> - Say we completed the I/O by returning OKAY
> 
> I agree it's not nice, and bouncing would have been preferable, but that's 
> the way 'wide I/O' works.

I see. Which means
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan


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