On LoongArch system, there is only virt machine type now, name
LOONGARCH_MACHINE is confused, rename it with VIRT_MACHINE. Machine name
about Other real hw boards can be added in future.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
---
hw/loongarch/acpi-build.c | 8 ++++----
hw/loongarch/boot.c | 2 +-
hw/loongarch/virt.c | 19 +++++++++----------
include/hw/loongarch/virt.h | 4 ++--
4 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/hw/loongarch/acpi-build.c b/hw/loongarch/acpi-build.c
index e5ab1080af..72322cdb1e 100644
--- a/hw/loongarch/acpi-build.c
+++ b/hw/loongarch/acpi-build.c
@@ -167,7 +167,7 @@ build_srat(GArray *table_data, BIOSLinker *linker, MachineState *machine)
int i, arch_id, node_id;
uint64_t mem_len, mem_base;
int nb_numa_nodes = machine->numa_state->num_nodes;
- LoongArchMachineState *lams = LOONGARCH_MACHINE(machine);
+ LoongArchMachineState *lams = VIRT_MACHINE(machine);
MachineClass *mc = MACHINE_GET_CLASS(lams);
const CPUArchIdList *arch_ids = mc->possible_cpu_arch_ids(machine);
AcpiTable table = { .sig = "SRAT", .rev = 1, .oem_id = lams->oem_id,
@@ -279,7 +279,7 @@ static void
build_la_ged_aml(Aml *dsdt, MachineState *machine)
{
uint32_t event;
- LoongArchMachineState *lams = LOONGARCH_MACHINE(machine);
+ LoongArchMachineState *lams = VIRT_MACHINE(machine);
build_ged_aml(dsdt, "\\_SB."GED_DEVICE,
HOTPLUG_HANDLER(lams->acpi_ged),
@@ -391,7 +391,7 @@ static void
build_dsdt(GArray *table_data, BIOSLinker *linker, MachineState *machine)
{
Aml *dsdt, *scope, *pkg;
- LoongArchMachineState *lams = LOONGARCH_MACHINE(machine);
+ LoongArchMachineState *lams = VIRT_MACHINE(machine);
AcpiTable table = { .sig = "DSDT", .rev = 1, .oem_id = lams->oem_id,
.oem_table_id = lams->oem_table_id };
@@ -421,7 +421,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, MachineState *machine)
static void acpi_build(AcpiBuildTables *tables, MachineState *machine)
{
- LoongArchMachineState *lams = LOONGARCH_MACHINE(machine);
+ LoongArchMachineState *lams = VIRT_MACHINE(machine);
GArray *table_offsets;
AcpiFadtData fadt_data;
unsigned facs, rsdt, dsdt;
diff --git a/hw/loongarch/boot.c b/hw/loongarch/boot.c
index 7d1630b2e7..e46c70b1b3 100644
--- a/hw/loongarch/boot.c
+++ b/hw/loongarch/boot.c
@@ -316,7 +316,7 @@ static void loongarch_direct_kernel_boot(struct loongarch_boot_info *info)
void loongarch_load_kernel(MachineState *ms, struct loongarch_boot_info *info)
{
- LoongArchMachineState *lams = LOONGARCH_MACHINE(ms);
+ LoongArchMachineState *lams = VIRT_MACHINE(ms);
int i;
/* register reset function */
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index c0999878df..e343974b48 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -880,7 +880,7 @@ static void loongarch_init(MachineState *machine)
ram_addr_t ram_size = machine->ram_size;
uint64_t highram_size = 0, phyAddr = 0;
MemoryRegion *address_space_mem = get_system_memory();
- LoongArchMachineState *lams = LOONGARCH_MACHINE(machine);
+ LoongArchMachineState *lams = VIRT_MACHINE(machine);
int nb_numa_nodes = machine->numa_state->num_nodes;
NodeInfo *numa_info = machine->numa_state->nodes;
int i;
@@ -1032,7 +1032,7 @@ bool loongarch_is_acpi_enabled(LoongArchMachineState *lams)
static void loongarch_get_acpi(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
- LoongArchMachineState *lams = LOONGARCH_MACHINE(obj);
+ LoongArchMachineState *lams = VIRT_MACHINE(obj);
OnOffAuto acpi = lams->acpi;
visit_type_OnOffAuto(v, name, &acpi, errp);
@@ -1041,14 +1041,14 @@ static void loongarch_get_acpi(Object *obj, Visitor *v, const char *name,
static void loongarch_set_acpi(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
- LoongArchMachineState *lams = LOONGARCH_MACHINE(obj);
+ LoongArchMachineState *lams = VIRT_MACHINE(obj);
visit_type_OnOffAuto(v, name, &lams->acpi, errp);
}
static void loongarch_machine_initfn(Object *obj)
{
- LoongArchMachineState *lams = LOONGARCH_MACHINE(obj);
+ LoongArchMachineState *lams = VIRT_MACHINE(obj);
lams->acpi = ON_OFF_AUTO_AUTO;
lams->oem_id = g_strndup(ACPI_BUILD_APPNAME6, 6);
@@ -1080,7 +1080,7 @@ static void virt_machine_device_pre_plug(HotplugHandler *hotplug_dev,
static void virt_mem_unplug_request(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp)
{
- LoongArchMachineState *lams = LOONGARCH_MACHINE(hotplug_dev);
+ LoongArchMachineState *lams = VIRT_MACHINE(hotplug_dev);
/* the acpi ged is always exist */
hotplug_handler_unplug_request(HOTPLUG_HANDLER(lams->acpi_ged), dev,
@@ -1098,7 +1098,7 @@ static void virt_machine_device_unplug_request(HotplugHandler *hotplug_dev,
static void virt_mem_unplug(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp)
{
- LoongArchMachineState *lams = LOONGARCH_MACHINE(hotplug_dev);
+ LoongArchMachineState *lams = VIRT_MACHINE(hotplug_dev);
hotplug_handler_unplug(HOTPLUG_HANDLER(lams->acpi_ged), dev, errp);
pc_dimm_unplug(PC_DIMM(dev), MACHINE(lams));
@@ -1116,7 +1116,7 @@ static void virt_machine_device_unplug(HotplugHandler *hotplug_dev,
static void virt_mem_plug(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp)
{
- LoongArchMachineState *lams = LOONGARCH_MACHINE(hotplug_dev);
+ LoongArchMachineState *lams = VIRT_MACHINE(hotplug_dev);
pc_dimm_plug(PC_DIMM(dev), MACHINE(lams));
hotplug_handler_plug(HOTPLUG_HANDLER(lams->acpi_ged),
@@ -1126,7 +1126,7 @@ static void virt_mem_plug(HotplugHandler *hotplug_dev,
static void loongarch_machine_device_plug_cb(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp)
{
- LoongArchMachineState *lams = LOONGARCH_MACHINE(hotplug_dev);
+ LoongArchMachineState *lams = VIRT_MACHINE(hotplug_dev);
MachineClass *mc = MACHINE_GET_CLASS(lams);
if (device_is_dynamic_sysbus(mc, dev)) {
@@ -1208,7 +1208,6 @@ static void loongarch_class_init(ObjectClass *oc, void *data)
MachineClass *mc = MACHINE_CLASS(oc);
HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);
- mc->desc = "Loongson-3A5000 LS7A1000 machine";
mc->init = loongarch_init;
mc->default_ram_size = 1 * GiB;
mc->default_cpu_type = LOONGARCH_CPU_TYPE_NAME("la464");
@@ -1245,7 +1244,7 @@ static void loongarch_class_init(ObjectClass *oc, void *data)
static const TypeInfo loongarch_machine_types[] = {
{
- .name = TYPE_LOONGARCH_MACHINE,
+ .name = TYPE_VIRT_MACHINE,
.parent = TYPE_MACHINE,
.instance_size = sizeof(LoongArchMachineState),
.class_init = loongarch_class_init,
diff --git a/include/hw/loongarch/virt.h b/include/hw/loongarch/virt.h
index 4e14bf6060..5ea2f0370d 100644
--- a/include/hw/loongarch/virt.h
+++ b/include/hw/loongarch/virt.h
@@ -73,8 +73,8 @@ struct LoongArchMachineState {
struct loongarch_boot_info bootinfo;
};
-#define TYPE_LOONGARCH_MACHINE MACHINE_TYPE_NAME("virt")
-OBJECT_DECLARE_SIMPLE_TYPE(LoongArchMachineState, LOONGARCH_MACHINE)
+#define TYPE_VIRT_MACHINE MACHINE_TYPE_NAME("virt")
+OBJECT_DECLARE_SIMPLE_TYPE(LoongArchMachineState, VIRT_MACHINE)
bool loongarch_is_acpi_enabled(LoongArchMachineState *lams);
void loongarch_acpi_setup(LoongArchMachineState *lams);
#endif
--
2.39.3On 06/05/2024 05.02, Bibo Mao wrote:
> On LoongArch system, there is only virt machine type now, name
> LOONGARCH_MACHINE is confused, rename it with VIRT_MACHINE. Machine name
> about Other real hw boards can be added in future.
>
> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
> ---
...
> @@ -1245,7 +1244,7 @@ static void loongarch_class_init(ObjectClass *oc, void *data)
>
> static const TypeInfo loongarch_machine_types[] = {
> {
> - .name = TYPE_LOONGARCH_MACHINE,
> + .name = TYPE_VIRT_MACHINE,
> .parent = TYPE_MACHINE,
> .instance_size = sizeof(LoongArchMachineState),
> .class_init = loongarch_class_init,
> diff --git a/include/hw/loongarch/virt.h b/include/hw/loongarch/virt.h
> index 4e14bf6060..5ea2f0370d 100644
> --- a/include/hw/loongarch/virt.h
> +++ b/include/hw/loongarch/virt.h
> @@ -73,8 +73,8 @@ struct LoongArchMachineState {
> struct loongarch_boot_info bootinfo;
> };
>
> -#define TYPE_LOONGARCH_MACHINE MACHINE_TYPE_NAME("virt")
> -OBJECT_DECLARE_SIMPLE_TYPE(LoongArchMachineState, LOONGARCH_MACHINE)
> +#define TYPE_VIRT_MACHINE MACHINE_TYPE_NAME("virt")
> +OBJECT_DECLARE_SIMPLE_TYPE(LoongArchMachineState, VIRT_MACHINE)
> bool loongarch_is_acpi_enabled(LoongArchMachineState *lams);
> void loongarch_acpi_setup(LoongArchMachineState *lams);
> #endif
Hi,
there are currently some efforts going on to create the possibility to link
a QEMU binary that contains all targets in one binary. Since we already have
a TYPE_VIRT_MACHINE for other targets, I wonder whether it might be better
to use LOONGARCH_VIRT_MACHINE than just VIRT_MACHINE here? Philippe, could
you comment on this?
Thomas
On 2024/5/6 下午12:24, Thomas Huth wrote:
> On 06/05/2024 05.02, Bibo Mao wrote:
>> On LoongArch system, there is only virt machine type now, name
>> LOONGARCH_MACHINE is confused, rename it with VIRT_MACHINE. Machine name
>> about Other real hw boards can be added in future.
>>
>> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
>> ---
> ...
>> @@ -1245,7 +1244,7 @@ static void loongarch_class_init(ObjectClass
>> *oc, void *data)
>> static const TypeInfo loongarch_machine_types[] = {
>> {
>> - .name = TYPE_LOONGARCH_MACHINE,
>> + .name = TYPE_VIRT_MACHINE,
>> .parent = TYPE_MACHINE,
>> .instance_size = sizeof(LoongArchMachineState),
>> .class_init = loongarch_class_init,
>> diff --git a/include/hw/loongarch/virt.h b/include/hw/loongarch/virt.h
>> index 4e14bf6060..5ea2f0370d 100644
>> --- a/include/hw/loongarch/virt.h
>> +++ b/include/hw/loongarch/virt.h
>> @@ -73,8 +73,8 @@ struct LoongArchMachineState {
>> struct loongarch_boot_info bootinfo;
>> };
>> -#define TYPE_LOONGARCH_MACHINE MACHINE_TYPE_NAME("virt")
>> -OBJECT_DECLARE_SIMPLE_TYPE(LoongArchMachineState, LOONGARCH_MACHINE)
>> +#define TYPE_VIRT_MACHINE MACHINE_TYPE_NAME("virt")
>> +OBJECT_DECLARE_SIMPLE_TYPE(LoongArchMachineState, VIRT_MACHINE)
>> bool loongarch_is_acpi_enabled(LoongArchMachineState *lams);
>> void loongarch_acpi_setup(LoongArchMachineState *lams);
>> #endif
>
> Hi,
>
> there are currently some efforts going on to create the possibility to
> link a QEMU binary that contains all targets in one binary. Since we
> already have a TYPE_VIRT_MACHINE for other targets, I wonder whether it
> might be better to use LOONGARCH_VIRT_MACHINE than just VIRT_MACHINE
> here? Philippe, could you comment on this?
It is great if there is one QEMU binary which supports different
targets. And LOONGARCH_VIRT_MACHINE is ok for me.
Regards
Bibo Mao
>
> Thomas
On 2024/5/6 下午2:09, maobibo wrote:
>
>
> On 2024/5/6 下午12:24, Thomas Huth wrote:
>> On 06/05/2024 05.02, Bibo Mao wrote:
>>> On LoongArch system, there is only virt machine type now, name
>>> LOONGARCH_MACHINE is confused, rename it with VIRT_MACHINE. Machine name
>>> about Other real hw boards can be added in future.
>>>
>>> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
>>> ---
>> ...
>>> @@ -1245,7 +1244,7 @@ static void loongarch_class_init(ObjectClass
>>> *oc, void *data)
>>> static const TypeInfo loongarch_machine_types[] = {
>>> {
>>> - .name = TYPE_LOONGARCH_MACHINE,
>>> + .name = TYPE_VIRT_MACHINE,
>>> .parent = TYPE_MACHINE,
>>> .instance_size = sizeof(LoongArchMachineState),
>>> .class_init = loongarch_class_init,
>>> diff --git a/include/hw/loongarch/virt.h b/include/hw/loongarch/virt.h
>>> index 4e14bf6060..5ea2f0370d 100644
>>> --- a/include/hw/loongarch/virt.h
>>> +++ b/include/hw/loongarch/virt.h
>>> @@ -73,8 +73,8 @@ struct LoongArchMachineState {
>>> struct loongarch_boot_info bootinfo;
>>> };
>>> -#define TYPE_LOONGARCH_MACHINE MACHINE_TYPE_NAME("virt")
>>> -OBJECT_DECLARE_SIMPLE_TYPE(LoongArchMachineState, LOONGARCH_MACHINE)
>>> +#define TYPE_VIRT_MACHINE MACHINE_TYPE_NAME("virt")
>>> +OBJECT_DECLARE_SIMPLE_TYPE(LoongArchMachineState, VIRT_MACHINE)
>>> bool loongarch_is_acpi_enabled(LoongArchMachineState *lams);
>>> void loongarch_acpi_setup(LoongArchMachineState *lams);
>>> #endif
>>
>> Hi,
>>
>> there are currently some efforts going on to create the possibility to
>> link a QEMU binary that contains all targets in one binary. Since we
>> already have a TYPE_VIRT_MACHINE for other targets, I wonder whether
>> it might be better to use LOONGARCH_VIRT_MACHINE than just
>> VIRT_MACHINE here? Philippe, could you comment on this?
>
> It is great if there is one QEMU binary which supports different
> targets. And LOONGARCH_VIRT_MACHINE is ok for me.
Hi Thomas, Philippe,
Does machine name "virt" need be changed if LOONGARCH_VIRT_MACHINE is
used? There will be compatible issues if "virt" machine type is not
suggested to use.
However CPU type "max" is not widely used now, can we get different
architectures from CPU type rather than machine type for one QEMU binary
which supports different targets?
Regards
Bibo Mao
>
> Regards
> Bibo Mao
>>
>> Thomas
>
On 07/05/2024 03.18, maobibo wrote:
>
>
> On 2024/5/6 下午2:09, maobibo wrote:
>>
>>
>> On 2024/5/6 下午12:24, Thomas Huth wrote:
>>> On 06/05/2024 05.02, Bibo Mao wrote:
>>>> On LoongArch system, there is only virt machine type now, name
>>>> LOONGARCH_MACHINE is confused, rename it with VIRT_MACHINE. Machine name
>>>> about Other real hw boards can be added in future.
>>>>
>>>> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
>>>> ---
>>> ...
>>>> @@ -1245,7 +1244,7 @@ static void loongarch_class_init(ObjectClass *oc,
>>>> void *data)
>>>> static const TypeInfo loongarch_machine_types[] = {
>>>> {
>>>> - .name = TYPE_LOONGARCH_MACHINE,
>>>> + .name = TYPE_VIRT_MACHINE,
>>>> .parent = TYPE_MACHINE,
>>>> .instance_size = sizeof(LoongArchMachineState),
>>>> .class_init = loongarch_class_init,
>>>> diff --git a/include/hw/loongarch/virt.h b/include/hw/loongarch/virt.h
>>>> index 4e14bf6060..5ea2f0370d 100644
>>>> --- a/include/hw/loongarch/virt.h
>>>> +++ b/include/hw/loongarch/virt.h
>>>> @@ -73,8 +73,8 @@ struct LoongArchMachineState {
>>>> struct loongarch_boot_info bootinfo;
>>>> };
>>>> -#define TYPE_LOONGARCH_MACHINE MACHINE_TYPE_NAME("virt")
>>>> -OBJECT_DECLARE_SIMPLE_TYPE(LoongArchMachineState, LOONGARCH_MACHINE)
>>>> +#define TYPE_VIRT_MACHINE MACHINE_TYPE_NAME("virt")
>>>> +OBJECT_DECLARE_SIMPLE_TYPE(LoongArchMachineState, VIRT_MACHINE)
>>>> bool loongarch_is_acpi_enabled(LoongArchMachineState *lams);
>>>> void loongarch_acpi_setup(LoongArchMachineState *lams);
>>>> #endif
>>>
>>> Hi,
>>>
>>> there are currently some efforts going on to create the possibility to
>>> link a QEMU binary that contains all targets in one binary. Since we
>>> already have a TYPE_VIRT_MACHINE for other targets, I wonder whether it
>>> might be better to use LOONGARCH_VIRT_MACHINE than just VIRT_MACHINE
>>> here? Philippe, could you comment on this?
>>
>> It is great if there is one QEMU binary which supports different targets.
>> And LOONGARCH_VIRT_MACHINE is ok for me.
> Hi Thomas, Philippe,
>
> Does machine name "virt" need be changed if LOONGARCH_VIRT_MACHINE is used?
> There will be compatible issues if "virt" machine type is not suggested to use.
>
> However CPU type "max" is not widely used now, can we get different
> architectures from CPU type rather than machine type for one QEMU binary
> which supports different targets?
I assume it should be fine to keep the "virt" machine name and "max" CPU
type for each target, we've got a bunch of those already. I assume we'll
keep the binary names as symlinks to the generic binary around and then
decide via argv[0] about the main target...? Philippe, do you have already
concrete plans for this?
Thomas
On 2024/5/7 下午2:10, Thomas Huth wrote:
> On 07/05/2024 03.18, maobibo wrote:
>>
>>
>> On 2024/5/6 下午2:09, maobibo wrote:
>>>
>>>
>>> On 2024/5/6 下午12:24, Thomas Huth wrote:
>>>> On 06/05/2024 05.02, Bibo Mao wrote:
>>>>> On LoongArch system, there is only virt machine type now, name
>>>>> LOONGARCH_MACHINE is confused, rename it with VIRT_MACHINE. Machine
>>>>> name
>>>>> about Other real hw boards can be added in future.
>>>>>
>>>>> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
>>>>> ---
>>>> ...
>>>>> @@ -1245,7 +1244,7 @@ static void loongarch_class_init(ObjectClass
>>>>> *oc, void *data)
>>>>> static const TypeInfo loongarch_machine_types[] = {
>>>>> {
>>>>> - .name = TYPE_LOONGARCH_MACHINE,
>>>>> + .name = TYPE_VIRT_MACHINE,
>>>>> .parent = TYPE_MACHINE,
>>>>> .instance_size = sizeof(LoongArchMachineState),
>>>>> .class_init = loongarch_class_init,
>>>>> diff --git a/include/hw/loongarch/virt.h b/include/hw/loongarch/virt.h
>>>>> index 4e14bf6060..5ea2f0370d 100644
>>>>> --- a/include/hw/loongarch/virt.h
>>>>> +++ b/include/hw/loongarch/virt.h
>>>>> @@ -73,8 +73,8 @@ struct LoongArchMachineState {
>>>>> struct loongarch_boot_info bootinfo;
>>>>> };
>>>>> -#define TYPE_LOONGARCH_MACHINE MACHINE_TYPE_NAME("virt")
>>>>> -OBJECT_DECLARE_SIMPLE_TYPE(LoongArchMachineState, LOONGARCH_MACHINE)
>>>>> +#define TYPE_VIRT_MACHINE MACHINE_TYPE_NAME("virt")
>>>>> +OBJECT_DECLARE_SIMPLE_TYPE(LoongArchMachineState, VIRT_MACHINE)
>>>>> bool loongarch_is_acpi_enabled(LoongArchMachineState *lams);
>>>>> void loongarch_acpi_setup(LoongArchMachineState *lams);
>>>>> #endif
>>>>
>>>> Hi,
>>>>
>>>> there are currently some efforts going on to create the possibility
>>>> to link a QEMU binary that contains all targets in one binary. Since
>>>> we already have a TYPE_VIRT_MACHINE for other targets, I wonder
>>>> whether it might be better to use LOONGARCH_VIRT_MACHINE than just
>>>> VIRT_MACHINE here? Philippe, could you comment on this?
>>>
>>> It is great if there is one QEMU binary which supports different
>>> targets. And LOONGARCH_VIRT_MACHINE is ok for me.
>> Hi Thomas, Philippe,
>>
>> Does machine name "virt" need be changed if LOONGARCH_VIRT_MACHINE is
>> used? There will be compatible issues if "virt" machine type is not
>> suggested to use.
>>
>> However CPU type "max" is not widely used now, can we get different
>> architectures from CPU type rather than machine type for one QEMU
>> binary which supports different targets?
>
> I assume it should be fine to keep the "virt" machine name and "max" CPU
> type for each target, we've got a bunch of those already. I assume we'll
> keep the binary names as symlinks to the generic binary around and then
> decide via argv[0] about the main target...? Philippe, do you have
> already concrete plans for this?
The method using symlinks to generic binary is great. It is transparent
to detailed architectures. I will refresh the patch and use
LOONGARCH_VIRT_MACHINE macro.
Regards
Bibo Mao
>
> Thomas
>
>
© 2016 - 2024 Red Hat, Inc.