[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 16/17] x86/hvm: always re-emulate I/O from a buffer
> -----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. Paul > Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |