[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2] coverity-model: model address_space_read/wri
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH v2] coverity-model: model address_space_read/write |
Date: |
Wed, 15 Mar 2017 07:19:31 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
On 03/15/2017 06:58 AM, Peter Maydell wrote:
> On 15 March 2017 at 11:55, Eric Blake <address@hidden> 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 <address@hidden>
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature