qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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



  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).