On 17.04.2025 16:16, Roger Pau Monné wrote:
> On Thu, Apr 17, 2025 at 09:43:09AM +0200, Jan Beulich wrote:
>> On 15.04.2025 17:32, Roger Pau Monne wrote:
>>> @@ -5115,7 +5115,6 @@ static void subpage_mmio_write_emulate(
>>>
>>> if ( test_bit(offset / MMIO_RO_SUBPAGE_GRAN, entry->ro_elems) )
>>> {
>>> - write_ignored:
>>> gprintk(XENLOG_WARNING,
>>> "ignoring write to R/O MMIO 0x%"PRI_mfn"%03x len %u\n",
>>> mfn_x(mfn), offset, len);
>>> @@ -5131,26 +5130,7 @@ static void subpage_mmio_write_emulate(
>>> return;
>>> }
>>>
>>> - addr += offset;
>>> - switch ( len )
>>> - {
>>> - case 1:
>>> - writeb(*(const uint8_t*)data, addr);
>>> - break;
>>> - case 2:
>>> - writew(*(const uint16_t*)data, addr);
>>> - break;
>>> - case 4:
>>> - writel(*(const uint32_t*)data, addr);
>>> - break;
>>> - case 8:
>>> - writeq(*(const uint64_t*)data, addr);
>>> - break;
>>> - default:
>>> - /* mmio_ro_emulated_write() already validated the size */
>>> - ASSERT_UNREACHABLE();
>>> - goto write_ignored;
>>> - }
>>> + write_mmio(addr + offset, data, len);
>>> }
>>
>> Should probably have noticed this on v1 already: The log message is now lost
>> for the write-ignored case. It looks easy enough to have the function return
>> a boolean indicating "done", to retain original behavior here.
>
> Hm, I didn't seem to me the message wants conserving, as it's
> unreachable code. I can try to add again, but we don't print such
> message in other cases.
This sub-page stuff is special, but I wouldn't mind if we dropped the
message altogether. The "unreachable code" argument is slightly weak,
as it's in particular when the assumption is violated that we would
want to know about it.
Jan
