Re: [Qemu-devel] [PATCH] q35/mch: implement extended TSEG sizes

[Laszlo Ersek]

On 06/08/17 18:34, Paolo Bonzini wrote:
> 
> 
> On 08/06/2017 18:10, Laszlo Ersek wrote:
>> When the guest writes value 0xffff to this register, the value that can be
>> read back is that of "mch.extended-tseg-mbytes" -- unless it remains
>> 0xffff. The guest is required to write 0xffff first (as opposed to a
>> read-only register) because PCI config space is generally not cleared on
>> QEMU reset, and after S3 resume or reboot, new guest firmware running on
>> old QEMU could read a guest OS-injected value from this register.
> 
> I guess that's also a reason not to make it readonly (that is, it would
> require some firmware code anyway to test for "readonlyness" and
> distinguish old machine types from new)?

That's right; in
<https://lists.01.org/pipermail/edk2-devel/2017-May/010432.html> I wrote,

> If we invent such a new register, it should be in a location that is
> either read-only, or zeroed-on-reset, in current QEMU. Otherwise, new
> firmware running on old QEMU could be misled by a guest OS that writes
> to this register, and then either reboots or enters S3.
>
> ... With this in mind, I don't oppose "having to write somewhere to
> read back the result", but then let's please make that write access as
> well to the same new qemu-specific register, and not to MCH_ESMRAMC.

The problem is that config space is by default r/w and not cleared on
reboot -- see Gerd's
<https://lists.01.org/pipermail/edk2-devel/2017-May/010456.html> --, and
once we designate another offset as "special" (either "reactive" or
"read only"), the firmware will have to write to it and read it back
unconditionally, to tell it apart from the default / original /
non-special config space.

Thanks!
Laszlo