From: Shaoqin Huang <shahuang@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Eric Auger" <eauger@redhat.com>,
qemu-arm@nongnu.org, "Peter Maydell" <peter.maydell@linaro.org>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Cédric Le Goater" <clg@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH v4 2/2] hw/i386: Add the ramfb romfile compatatibility
Date: Fri, 27 Jun 2025 16:30:50 +0800 [thread overview]
Message-ID: <3000f15b-9296-44ac-81aa-c95b7c6d3a7e@redhat.com> (raw)
In-Reply-To: <aF5FD-mvsh5-eMcX@redhat.com>
Hi Daniel,
On 6/27/25 3:15 PM, Daniel P. Berrangé wrote:
> On Fri, Jun 27, 2025 at 01:37:55PM +0800, Shaoqin Huang wrote:
>> Hi Eric,
>>
>> On 6/26/25 4:01 PM, Eric Auger wrote:
>>>
>>>
>>> On 6/26/25 4:05 AM, Shaoqin Huang wrote:
>>>> Hi Eric,
>>>>
>>>> On 6/23/25 5:20 PM, Eric Auger wrote:
>>>>>
>>>>>
>>>>> On 6/17/25 5:05 AM, Shaoqin Huang wrote:
>>>>>> Set the "use-legacy-x86-rom" property to false by default, and only set
>>>>>> it to true on x86 since only x86 will need it.
>>>>> s/compatatibility/compatibility in the title
>>>>
>>>> Ok. Will fix it.
>>>>
>>>>>>
>>>>>> Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
>>>>>> ---
>>>>>> hw/display/ramfb-standalone.c | 2 +-
>>>>>> hw/i386/pc_q35.c | 3 +++
>>>>>> hw/vfio/pci.c | 2 +-
>>>>>> 3 files changed, 5 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/hw/display/ramfb-standalone.c b/hw/display/ramfb-
>>>>>> standalone.c
>>>>>> index af1175bf96..ddbf42f181 100644
>>>>>> --- a/hw/display/ramfb-standalone.c
>>>>>> +++ b/hw/display/ramfb-standalone.c
>>>>>> @@ -63,7 +63,7 @@ static const VMStateDescription ramfb_dev_vmstate = {
>>>>>> static const Property ramfb_properties[] = {
>>>>>> DEFINE_PROP_BOOL("x-migrate", RAMFBStandaloneState, migrate,
>>>>>> true),
>>>>>> - DEFINE_PROP_BOOL("use-legacy-x86-rom", RAMFBStandaloneState,
>>>>>> use_legacy_x86_rom, true),
>>>>>> + DEFINE_PROP_BOOL("use-legacy-x86-rom", RAMFBStandaloneState,
>>>>>> use_legacy_x86_rom, false),
>>>>>> };
>>>>>> static void ramfb_class_initfn(ObjectClass *klass, void *data)
>>>>>> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
>>>>>> index fd96d0345c..f6d89578d0 100644
>>>>>> --- a/hw/i386/pc_q35.c
>>>>>> +++ b/hw/i386/pc_q35.c
>>>>>> @@ -45,6 +45,7 @@
>>>>>> #include "hw/i386/pc.h"
>>>>>> #include "hw/i386/amd_iommu.h"
>>>>>> #include "hw/i386/intel_iommu.h"
>>>>>> +#include "hw/vfio/pci.h"
>>>>>> #include "hw/virtio/virtio-iommu.h"
>>>>>> #include "hw/display/ramfb.h"
>>>>>> #include "hw/ide/pci.h"
>>>>>> @@ -67,6 +68,8 @@
>>>>>> static GlobalProperty pc_q35_compat_defaults[] = {
>>>>>> { TYPE_VIRTIO_IOMMU_PCI, "aw-bits", "39" },
>>>>>> + { TYPE_RAMFB_DEVICE, "use-legacy-x86-rom", "true" },
>>>>>> + { TYPE_VFIO_PCI, "use-legacy-x86-rom", "true" },
>>>>> this will only keep the legacy behavior along with q35 machine type but
>>>>> not on other machines being used for x86. what about pc-i440fx? Doesn't
>>>>> it apply to it as well? Are there other machine types also impacted.
>>>>
>>>> Ok I will also add it with pc-i440fx. I think only q35 and i440fx are
>>>> impacted.
>>>>
>>>>>
>>>>> Also what about Daniel's comment in v3:
>>>>> https://lore.kernel.org/all/aEak8utPPkHepVfR@redhat.com/
>>>>> "For non-x86, historical versioned machine types will need
>>>>> likely it set to true, in order to avoid the memory layout
>>>>> being changed IIUC."
>>>>>
>>>>> Is it actually needed?
>>>>
>>>> If those machine types need to set it to true. I think they can set it
>>>> after they have this property.
>>> nope it does not work like that. In case we really need to take care of
>>> this, this must be handled by compats.
>>
>> If so. Why don't we still keep the "use-legacy-x86-rom" default to true, and
>> only set it to false to those arch which doesn't need it just like my
>> original implementation.
>>
>> Because I don't really know how other arch's memoery layout was impacted by
>> this property set to false. I think keep their original behavior and only
>> change it on arm64 is a good idea.
>>
>> How do you think about it?
>
> No, the default value of the property shoudl reflect the long
> term desired behaviour - in this case 'use-legacy-x86-rom = false'.
Ok I understand your thoughts.
>
> We must then reverse this default to 'true' for ALL historical versioned
> machine types on ALL architectures, where this device is built, or any
> specific machines where we want to keep the historical behaviour going
> forward.
But how do we implement that?
Maybe set the 'use-legacy-x86-rom = true' in hw_compat_9_2 ?
I'm not sure about that, could you give some hints about how to reverse
the default to 'true' for ALL historical versioned machine types?
Thanks a lot.
>
>
> With regards,
> Daniel
--
Shaoqin
next prev parent reply other threads:[~2025-06-27 8:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-17 3:05 [PATCH v4 0/2] ramfb: Add property to control if load the romfile Shaoqin Huang
2025-06-17 3:05 ` [PATCH v4 1/2] " Shaoqin Huang
2025-06-23 9:20 ` Eric Auger
2025-06-26 1:55 ` Shaoqin Huang
2025-06-17 3:05 ` [PATCH v4 2/2] hw/i386: Add the ramfb romfile compatatibility Shaoqin Huang
2025-06-23 9:20 ` Eric Auger
2025-06-26 2:05 ` Shaoqin Huang
2025-06-26 8:01 ` Eric Auger
2025-06-27 5:37 ` Shaoqin Huang
2025-06-27 7:15 ` Daniel P. Berrangé
2025-06-27 8:30 ` Shaoqin Huang [this message]
2025-07-01 12:04 ` Gerd Hoffmann
2025-07-01 12:56 ` Eric Auger
2025-06-23 2:17 ` [PATCH v4 0/2] ramfb: Add property to control if load the romfile Shaoqin Huang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3000f15b-9296-44ac-81aa-c95b7c6d3a7e@redhat.com \
--to=shahuang@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=berrange@redhat.com \
--cc=clg@redhat.com \
--cc=eauger@redhat.com \
--cc=eduardo@habkost.net \
--cc=kraxel@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).