Re: IO port write width clamping differs between TCG and KVM

[Laszlo Ersek <lersek@redhat.com>]

(Adding Gerd.)

On 1/4/23 08:23, Philippe Mathieu-Daudé wrote:
> Hi Laszlo,
>
> Happy new year!

Happy new year! :) Sorry for not responding earlier, I was busy writing
& testing the patch.

[...]

>> However, what I *really* don't understand is why this commit
>> (5d971f9e672507210e77d020d89e0e89165c8fc9) makes a difference *only*
>> under TCG.

So this remains a mistery to me...

>
> Is it easily reproducible with TCG?

Yes and no.

If you have an OVMF binary built for the DEBUG or NOOPT target, then
it's nearly trivial:

qemu-system-i386 \
  -M accel=tcg \
  -smp 2 \
  -drive if=pflash,file=edk2-i386-code.fd,readonly=on \
  -drive if=pflash,file=edk2-i386-vars.fd,snapshot=on \
  -m 512 \
  -global isa-debugcon.iobase=0x402 \
  -debugcon file:/tmp/debug.log

Without the fix, you find near the top of "/tmp/debug.log":

  MaxCpuCountInitialization: QEMU v2.7 reset bug: BootCpuCount=2 Present=0
  MaxCpuCountInitialization: BootCpuCount=0 mMaxCpuCount=1

Note that here OVMF is led to believe that the system has 2 possible
CPUs, and *zero* enabled one :)

(Side comment: don't be confused by the "QEMU v2.7 reset bug" message.
That is a workaround in OVMF for a *different* QEMU bug. Unfortunately,
the workaround is unexpectedly triggered by *this* other QEMU bug as
well, but *opposite* to the intent.)

With the fix, you see, in the log:

  MaxCpuCountInitialization: BootCpuCount=2 mMaxCpuCount=2

Unfortunately, this simple reproducer does not work with the
QEMU-bundled binaries, because of commit ca26041500eb ("edk2: switch to
release builds", 2022-03-15). The switch to the RELEASE target indeed
speeds up the OVMF binaries, but it also eliminates all ASSERT()s and
DEBUG messages from the code. Therefore you'll get an empty
"/tmp/debug.log" with the above command.

Gerd, any particular reason for commit ca26041500eb? (The commit doesn't
say.)

I've found another small omission, namely in the same  patch series that
contains the above commit. While commit 3891a5996fee ("edk2: update
binaries to stable202202", 2022-03-15) updated the binaries, there was
no separate patch to refresh the accompanying text in "pc-bios/README".

For an earlier example, refer to 419236601eb2 ("pc-bios: update the
README file with edk2-stable202008 information", 2020-09-13).

Thus, at the moment, "pc-bios/README" is stale.

I'd recommend two things:

- restoring (or re-introducing, as separate binaries?) the DEBUG builds,

- refreshing "pc-bios/README".

Laszlo