On 03/15/2017 06:58 AM, Peter Maydell wrote: > On 15 March 2017 at 11:55, Eric Blake <[email protected]> wrote: >> On 03/15/2017 03:16 AM, Paolo Bonzini wrote: >>> -MemTxResult address_space_rw(AddressSpace *as, hwaddr addr, MemTxAttrs >>> attrs, >>> - uint8_t *buf, int len, bool is_write) >>> +MemTxResult address_space_read(AddressSpace *as, hwaddr addr, >>> + MemTxAttrs attrs, >>> + uint8_t *buf, int len) >>> { >>> MemTxResult result; >>> - >>> // TODO: investigate impact of treating reads as producing >>> // tainted data, with __coverity_tainted_data_argument__(buf). >>> - if (is_write) __bufread(buf, len); else __bufwrite(buf, len); >> >> Old code did __bufread for reads, > > Eh? for a read is_write is false, and we use the else clause, > which is __bufwrite...
Maybe I shouldn't send emails when I've just woken up? It threw me that we have a function named 'read' relying on coverity's 'write' - but you're correct that it has always been that way, and thinking about it more, what is really happening is: our function named 'read' is emulating getting data from hardware (the 'read' portion) and copying it into the buffer (the 'write' portion); the Coverity model needs to know about the effects to the buffer, but could care less about the hardware emulation side. Okay, you've straightened me out, so I can give: Reviewed-by: Eric Blake <[email protected]> -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
