[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 2/4] Memory: Enable writeback for given memory region
From: |
Alex Bennée |
Subject: |
Re: [PATCH v2 2/4] Memory: Enable writeback for given memory region |
Date: |
Thu, 07 Nov 2019 16:57:21 +0000 |
User-agent: |
mu4e 1.3.5; emacs 27.0.50 |
Beata Michalska <address@hidden> writes:
> On Wed, 6 Nov 2019 at 12:20, Richard Henderson
> <address@hidden> wrote:
>>
>> On 11/6/19 12:40 AM, Beata Michalska wrote:
>> > +void qemu_ram_writeback(RAMBlock *block, ram_addr_t start, ram_addr_t
>> > length)
>> > +{
>> > + void *addr = ramblock_ptr(block, start);
>> > +
>> > + /*
>> > + * The requested range might spread up to the very end of the block
>> > + */
>> > + if ((start + length) > block->used_length) {
>> > + qemu_log("%s: sync range outside the block boundaries: "
>> > + "start: " RAM_ADDR_FMT " length: " RAM_ADDR_FMT
>> > + " block length: " RAM_ADDR_FMT " Narrowing down ..."
>> > ,
>> > + __func__, start, length, block->used_length);
>> > + length = block->used_length - start;
>> > + }
>>
>> qemu_log_mask w/ GUEST_ERROR? How do we expect the length to overflow?
>
> In theory it shouldn't, at least with current usage.
> I guess the probe_access will make sure of that.
> This was more of a precaution to enable catching potential/future misuses
> aka debugging purpose. I can get rid of that it that's playing too
> safe.
If the internal code might get it wrong and that would be a bug then the
g_assert(), if the values are ultimately from the guest then log with
GUEST_ERROR as Richard suggests.
<snip>
--
Alex Bennée
[PATCH v2 3/4] migration: ram: Switch to ram block writeback, Beata Michalska, 2019/11/05
[PATCH v2 4/4] target/arm: Add support for DC CVAP & DC CVADP ins, Beata Michalska, 2019/11/05