Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated

2024-03-27 Thread Bernhard Beschow


Am 26. März 2024 13:29:58 UTC schrieb "Philippe Mathieu-Daudé" 
:
>Hi Igor,
>
>On 26/3/24 14:08, Thomas Huth wrote:
>> 
>> s/iaspc/isapc/ in the subject
>> 
>> On 26/03/2024 13.51, Igor Mammedov wrote:
>>> ISAPC machine was introduced 25 years ago and it's a lot of time since
>>> such machine was around with real ISA only PC hardware practically defunct.
>>> Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 
>>> host
>>> in only TCG mode, while in KVM mode it hung in the middle of boot)
>
>I'm quite opposed to this patch. QEMU models various very-old /
>defunct hardware. I'm pretty sure Bernhard and myself are OK to
>keep maintaining it, besides we are working in separating it from
>the i440fx+piix machine.

Yes, I'd rather keep maintaining the isapc machine and separating it from the 
i440fx machine seems like a good idea to me. I'm confident that we can work out 
a way that allows for moving forward the pc-pci machines while keeping the 
isapc machine from getting into the way too much.

Best regards,
Bernhard

> Also, this machine is particularly
>interesting for my single-binary experiments.
>
>Where I agree is we should stop reporting "KVM on ISA/PC machine"
>as supported.
>
>Regards,
>
>Phil.
>
>>> Rather than spending time on fixing 'the oldest' no longer tested machine 
>>> type,
>>> deprecate it so we can clean up QEMU code from legacy fixups and hopefully
>>> make it easier to follow.
>>> 
>>> Folks who have to use ancient guest that requires ISAPC can still
>>> use older QEMU to play with it.
>>> 
>>> Signed-off-by: Igor Mammedov 
>>> ---
>>>   docs/about/deprecated.rst | 7 +++
>>>   hw/i386/pc_piix.c | 1 +
>>>   2 files changed, 8 insertions(+)
>>> 
>>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
>>> index 7b548519b5..5708296991 100644
>>> --- a/docs/about/deprecated.rst
>>> +++ b/docs/about/deprecated.rst
>>> @@ -226,6 +226,13 @@ These old machine types are quite neglected nowadays 
>>> and thus might have
>>>   various pitfalls with regards to live migration. Use a newer machine type
>>>   instead.
>>> +``isapc`` (since 9.0)
>>> +'
>>> +
>>> +These old machine type are quite neglected nowadays and thus might have
>> 
>> "This old machine type is ..." ?
>> 
>>> +various pitfalls with regards to live migration. Use a newer machine type
>>> +instead.
>> 
>> I doubt that isapc could ever be used reliably for live migration, since 
>> it's an unversioned machine type, so I think it would be better to not 
>> mention live migration here.
>> 
>>   Thomas
>> 
>> 
>
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated

2024-03-27 Thread Paolo Bonzini
Il mer 27 mar 2024, 14:09 Igor Mammedov  ha scritto:

> It's question of whether we are willing to do unthinkable,
> i.e. to break QEMU <-> guest ABI for isapc case by removing
> corresponding fwcfg entries.
>

It's not unthinkable since it's unversioned.

we are loosing a chance to cleanup
> QEMU code base touching following
>
> m->option_rom_has_mr = true;
> m->rom_file_has_mr = false;
> pcmc->pci_enabled = false;
> pcmc->has_acpi_build = false;
> pcmc->smbios_defaults = false;
> pcmc->gigabyte_align = false;
> pcmc->smbios_legacy_mode = true;  pcmc->has_reserved_memory
> = false;
>

Some of these can go away, for the others probably we can think of making
isapc a direct subclass of X86MachineState.

I would rather keep it because it's the only way to test userspace
interrupt injection in KVM.

Paolo

they are all marginal but in shared code, and removing them
> makes code a bit more easier to follow (especially when it
> comes to memory layout).
>
> > With regards,
> > Daniel
>
>
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH-for-9.0? v2 1/3] fpu/softfloat: Remove mention of TILE-Gx target

2024-03-27 Thread Richard Henderson

On 3/27/24 04:48, Philippe Mathieu-Daudé wrote:

TILE-Gx has been removed during the v6.0 release (see
commit 2cc1a90166 "Remove deprecated target tilegx"),
no need to mention it in the list of "supported targets".

Signed-off-by: Philippe Mathieu-Daudé
---
  fpu/softfloat-specialize.c.inc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Reviewed-by: Richard Henderson 

r~
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH v2 1/1] remote: properly initialize objects in ACL helpers

2024-03-27 Thread Denis V. Lunev

On 3/19/24 15:07, Denis V. Lunev wrote:

Commit 2ecdf259299813c2c674377e22a0acbce5ccbbb2 was intended to
implement two things: reduce stack usage inside ACL helpers and
minimally initialize virDomainDef object to avoid passing garbage
inside validation framework. Though original commit has not
touched other ACL helpers.

This patch adds proper clauses to
 remoteRelayNetworkEventCheckACL
 remoteRelayStoragePoolEventCheckACL
 remoteRelayNodeDeviceEventCheckACL
 remoteRelaySecretEventCheckACL

Signed-off-by: Denis V. Lunev 
CC: Peter Krempa 
CC: Roman Grigoriev 
---
  src/remote/remote_daemon_dispatch.c | 32 ++---
  1 file changed, 16 insertions(+), 16 deletions(-)

Changes from v1:
* g_autoptr is replaced with g_autofree upon reached consensus
* patch 1 in series has been dropped

diff --git a/src/remote/remote_daemon_dispatch.c 
b/src/remote/remote_daemon_dispatch.c
index aaabd1e56c..b566a510b8 100644
--- a/src/remote/remote_daemon_dispatch.c
+++ b/src/remote/remote_daemon_dispatch.c
@@ -180,21 +180,21 @@ static bool
  remoteRelayNetworkEventCheckACL(virNetServerClient *client,
  virConnectPtr conn, virNetworkPtr net)
  {
-virNetworkDef def;
+g_autofree virNetworkDef *def = g_new0(virNetworkDef, 1);
  g_autoptr(virIdentity) identity = NULL;
  bool ret = false;
  
  /* For now, we just create a virNetworkDef with enough contents to

   * satisfy what viraccessdriverpolkit.c references.  This is a bit
   * fragile, but I don't know of anything better.  */
-def.name = net->name;
-memcpy(def.uuid, net->uuid, VIR_UUID_BUFLEN);
+def->name = net->name;
+memcpy(def->uuid, net->uuid, VIR_UUID_BUFLEN);
  
  if (!(identity = virNetServerClientGetIdentity(client)))

  goto cleanup;
  if (virIdentitySetCurrent(identity) < 0)
  goto cleanup;
-ret = virConnectNetworkEventRegisterAnyCheckACL(conn, );
+ret = virConnectNetworkEventRegisterAnyCheckACL(conn, def);
  
   cleanup:

  ignore_value(virIdentitySetCurrent(NULL));
@@ -206,21 +206,21 @@ remoteRelayStoragePoolEventCheckACL(virNetServerClient 
*client,
  virConnectPtr conn,
  virStoragePoolPtr pool)
  {
-virStoragePoolDef def;
+g_autofree virStoragePoolDef *def = g_new0(virStoragePoolDef, 1);
  g_autoptr(virIdentity) identity = NULL;
  bool ret = false;
  
  /* For now, we just create a virStoragePoolDef with enough contents to

   * satisfy what viraccessdriverpolkit.c references.  This is a bit
   * fragile, but I don't know of anything better.  */
-def.name = pool->name;
-memcpy(def.uuid, pool->uuid, VIR_UUID_BUFLEN);
+def->name = pool->name;
+memcpy(def->uuid, pool->uuid, VIR_UUID_BUFLEN);
  
  if (!(identity = virNetServerClientGetIdentity(client)))

  goto cleanup;
  if (virIdentitySetCurrent(identity) < 0)
  goto cleanup;
-ret = virConnectStoragePoolEventRegisterAnyCheckACL(conn, );
+ret = virConnectStoragePoolEventRegisterAnyCheckACL(conn, def);
  
   cleanup:

  ignore_value(virIdentitySetCurrent(NULL));
@@ -232,20 +232,20 @@ remoteRelayNodeDeviceEventCheckACL(virNetServerClient 
*client,
 virConnectPtr conn,
 virNodeDevicePtr dev)
  {
-virNodeDeviceDef def;
+g_autofree virNodeDeviceDef *def = g_new0(virNodeDeviceDef, 1);
  g_autoptr(virIdentity) identity = NULL;
  bool ret = false;
  
  /* For now, we just create a virNodeDeviceDef with enough contents to

   * satisfy what viraccessdriverpolkit.c references.  This is a bit
   * fragile, but I don't know of anything better.  */
-def.name = dev->name;
+def->name = dev->name;
  
  if (!(identity = virNetServerClientGetIdentity(client)))

  goto cleanup;
  if (virIdentitySetCurrent(identity) < 0)
  goto cleanup;
-ret = virConnectNodeDeviceEventRegisterAnyCheckACL(conn, );
+ret = virConnectNodeDeviceEventRegisterAnyCheckACL(conn, def);
  
   cleanup:

  ignore_value(virIdentitySetCurrent(NULL));
@@ -257,22 +257,22 @@ remoteRelaySecretEventCheckACL(virNetServerClient *client,
 virConnectPtr conn,
 virSecretPtr secret)
  {
-virSecretDef def;
+g_autofree virSecretDef *def = g_new0(virSecretDef, 1);
  g_autoptr(virIdentity) identity = NULL;
  bool ret = false;
  
  /* For now, we just create a virSecretDef with enough contents to

   * satisfy what viraccessdriverpolkit.c references.  This is a bit
   * fragile, but I don't know of anything better.  */
-memcpy(def.uuid, secret->uuid, VIR_UUID_BUFLEN);
-def.usage_type = secret->usageType;
-def.usage_id = secret->usageID;
+memcpy(def->uuid, secret->uuid, VIR_UUID_BUFLEN);
+def->usage_type = secret->usageType;
+

Re: [PATCH-for-9.0 v2] hw/i386/pc: Deprecate 64-bit CPUs on ISA-only PC machine

2024-03-27 Thread Philippe Mathieu-Daudé

On 27/3/24 18:29, Marcin Juszkiewicz wrote:

W dniu 27.03.2024 o 17:54, Philippe Mathieu-Daudé pisze:

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 7b548519b5..345c35507f 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -208,6 +208,13 @@ is no longer packaged in any distro making it 
harder to run the

  ``check-tcg`` tests. Unless we can improve the testing situation there
  is a chance the code will bitrot without anyone noticing.
+64-bit (x86_64) CPUs on the ``isapc`` machine (since 9.0)
+'
+
+The ``isapc`` machine aims to emulate old PC machine without PCI was
+generalized, so hardware available around 1995, before 64-bit intel
+CPUs were produced.


Can you s/Intel/x86-64/ here? Intel was not first with x86-64 (AMD 
invented it). Also "64-bit Intel" smells of Itanium too much.


OK ;)
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH 2/3] nodedev: immediate update of active config on udev add

2024-03-27 Thread Marc Hartmayer
On Wed, Mar 27, 2024 at 10:53 AM -0500, Jonathon Jongsma  
wrote:
> On 3/20/24 10:46 AM, Boris Fiuczynski wrote:
>> When an udev add event occurs the mdev active config data requires an
>> update via mdevctl as the udev does not contain all config data.
>> This update needs to occur immediate and to be finished before the
>> libvirt CREATE event is issued to keep the API usage reliable.
>
> The problem that you're trying to solve isn't spelled out very 
> explicitly here. My understanding is that the issue occurs when you 
> start a mediated device that has attributes (and the device is supported 
> by callout scripts in mdevctl). With the current code, my assumption is 
> that we observe the following behavior:
> - udev event is emitted
> - libvirt handles the udev event and emits a 
> VIR_NODE_DEVICE_EVENT_CREATED event for the new mdev. At this point the 
> mdev only information that is provided by udev (such as uuid, mdev type) 
> and doesn't include any attributes, for example.
> - we schedule a thread to query mdevctl for the full information for the 
> device. The mdev device gets update to include the full mdevctl data, 
> including attributes
> - libvirt emits a VIR_NODE_DEVICE_EVENT_ID_UPDATE event to indicate that 
> the device information was updated
>
> And you're trying to skip the last step and make sure that the 
> attributes are set at the time that the first CREATED event is
> emitted.

Boris is currently on vacation so I cannot discuss this with him, but
that’s my understanding as well. For me, this assumption also makes
sense… because otherwise it’s awkward to use the libvirt events API for
mdev devices (wait for a CREATED event and then for an UPDATE event for
the same device - not a really good UX pattern IMO).

[…snip…]

>>   
>> +/* The added mdev needs an immediate active config update before
>> + * the event is issues to allow sane API usage. */
>> +if (is_mdev && (nodeDeviceUpdateMediatedDevices() < 0))
>> +VIR_WARN("Update of mediated device %s failed",
>> + def ? NULLSTR(def->sysfs_path) : "");
>> +
>>   ret = 0;
>>   
>>cleanup:
>   ``
>
> Right now libvirt has a dedicated thread for handling udev updates, and 
> we also spawn a separate thread to query mdevctl whenever we detect that 
> mdev state has changed. This patch makes it so that mdevctl is now 
> executed directly from the udev thread, which changes that separation of 
> responsibilities. It shouldn't cause any memory corruption since 
> nodeDeviceUpdateMediatedDevices() is already threadsafe, but it makes 
> the code harder to reason about. When we introduced mdevctl support to 
> libvirt, the first versions of my patch series did in fact query mdevctl 
> from the udev thread. But based on concerns during code review, it was 
> moved out to a separate thread. So I don't think that we should 
> necessarily reintroduce that here.

Yep.

Right now we already have in node_device_udev:
+ init thread for initialization
+ udev thread, which creates and then enqueues the libvirt events
+ mdevctl update thread, which calls `nodeDeviceUpdateMediateDevices()‘
  (executing 'mdevctl' and updating the internal data structures with
  the result)
+ main thread for the timeout mechanism to launch the mdevCtlUpdateThread
+ another thread (not sure if it’s the main thread): virNodeDeviceUpdate -> 
nodeDeviceUpdateMediateDevices()

How about:
+ instead of having a mdevctl update thread and an init thread we could
  have only one worker pool (similar to qemu_process.c)
+ one udev thread that dispatches the events and then submits jobs to
  the worker pool
+ main thread for the timeout mechanism to schedule the “mdev update worker 
pool job”
+ another thread (not sure if it’s the main thread):
  virNodeDeviceUpdate: -> nodeDeviceUpdateMediateDevices() <- maybe we
  can leave it as is.

>
> In addition, I notice that udevHandleOneDevice() already schedules an 
> mdevctl update thread to be run after this function (udevAddOneDevice()) 
> is called for a mediated device. So after this patch, a new udev event 
> for a mediated device would result in the udev thread querying mdevctl 
> immediately and then also spawning a new thread to query mdevctl.

This can probably be removed after the patch from Boris.

>
> Jonathon
>
-- 
Kind regards / Beste Grüße
   Marc Hartmayer

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [libvirt PATCH] NEWS: Update

2024-03-27 Thread Andrea Bolognani
On Wed, Mar 27, 2024 at 04:07:13PM +0100, Ján Tomko wrote:
> Update NEWS with new news.
>
> Signed-off-by: Ján Tomko 
> ---
>  NEWS.rst | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/NEWS.rst b/NEWS.rst
> index ef9e312698..ce83ee629f 100644
> --- a/NEWS.rst
> +++ b/NEWS.rst
> @@ -36,6 +36,13 @@ v10.2.0 (unreleased)
>  use the upcoming QEMU 9.0.0 release together with the development version
>  of edk2.
>
> +  * qemu: Introduce virDomainGraphicsReload API
> +
> +Reloading the graphics display is now supported for QEMU guests using
> +VNC. This is useful to make QEMU reload the TLS certificats without

*certificates

> +restarting the guest. Available via the `virDomainGraphicsReload` API
> +and the `domdisplay-reload` virsh command.
> +
>  * **Improvements**
>
>  * **Bug fixes**
> @@ -52,6 +59,20 @@ v10.2.0 (unreleased)
>  releases to 10.2.0 works as well, but the other direction remains broken
>  unless the fix is backported.
>
> +  * qemu: set correct SELinux label for unprivileged virtiofsd
> +
> +Now, it's possible to use virtiofsd-based `` shares even
> +if the guest is confined using SELinux.

"It's now possible ..." reads better IMO. Up to you whether or not to
change it.

> +  * qemu: fix a crash on unprivileged virtiofsd hotplug
> +
> +Hotplugging virtiofsd-based filesystems works now.
> +
> +  * virt-admin: Fix segfault when libvirtd dies
> +
> +Now, `virt-admin` no longer crashes when `libvirtd` unexpectedly closes
> +the connection.

I'd just drop the initial "Now," here.


Throughout, you need to use ``reStructuredText preformatted text
quotes`` instead of `Markdown preformatted text quotes`.


With at least the typo and the quotes fixed,

  Reviewed-by: Andrea Bolognani 

-- 
Andrea Bolognani / Red Hat / Virtualization
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH-for-9.1] target/nios2: Remove machines and system emulation

2024-03-27 Thread Philippe Mathieu-Daudé

On 27/3/24 16:39, Thomas Huth wrote:

On 27/03/2024 15.15, Philippe Mathieu-Daudé wrote:

On 27/3/24 14:19, Thomas Huth wrote:

On 27/03/2024 13.45, Philippe Mathieu-Daudé wrote:

On 27/3/24 13:35, Philippe Mathieu-Daudé wrote:

Remove the Nios II machines and the system emulation code
(deprecated since v8.2 in commit 9997771bc1 "target/nios2:
Deprecate the Nios II architecture").




diff --git a/hw/nios2/Kconfig b/hw/nios2/Kconfig
deleted file mode 100644
index 4748ae27b6..00
--- a/hw/nios2/Kconfig
+++ /dev/null
@@ -1,13 +0,0 @@
-config NIOS2_10M50
-    bool
-    select NIOS2
-    select SERIAL
-    select ALTERA_TIMER


I forgot to mention I deliberately chose to keep the Altera
timer model in the tree, since it looks like a re-usable
IP component.


But if it is not used anymore by any machine, this will happily 
bitrot, won't it? I think I'd rather remove it, too ... maybe in a 
separate patch, so that in case somebody later needs it again, it can 
be restored by simply reverting the patch again.


It is related to dynamic machines, how do we decide what components
to remove once there? I suppose we'd need to deprecate every single
component, like ALTERA_TIMER. But we are not yet generating dynamic
machines, so for now we can consider ALTERA_TIMER part of Nios II
sysemu removal. I like your idea of removing it as a separate patch.


Even if we switch to dynamic machines one day, the devices still need to 
be somehow used and tested in the CI, e.g. by scripts that assemble a 
machine dynamically. If there's a device that is never used at all, we 
can also simply remove it until someone needs it again, I think.


Fair enough :)
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[RFC PATCH 0/2] One memory leak fix and one question

2024-03-27 Thread Marc Hartmayer
Marc Hartmayer (2):
  node_device_conf: virNodeDeviceGetSCSITargetCaps: fix memory leak
  TODO virNodeDeviceUpdateCaps: checks missing?

 src/conf/node_device_conf.c | 37 -
 1 file changed, 16 insertions(+), 21 deletions(-)

-- 
2.34.1
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.0 v2] hw/i386/pc: Deprecate 64-bit CPUs on ISA-only PC machine

2024-03-27 Thread Philippe Mathieu-Daudé
Per Daniel suggestion [*]:

 > isapc could arguably be restricted to just 32-bit CPU models,
 > because we should not need it to support any feature that didn't
 > exist prior to circa 1995. eg refuse to start with isapc, if 'lm'
 > is present in the CPU model for example.

Display a warning when such CPU is used:

  $ qemu-system-x86_64 -monitor stdio -S -M isapc -cpu Westmere
  qemu-system-x86_64: warning: Use of 64-bit CPU 'Westmere' is deprecated on 
the ISA-only PC machine
  QEMU 8.2.91 monitor - type 'help' for more information
  (qemu) q

  $ qemu-system-x86_64 -monitor stdio -S -M isapc -cpu athlon
  QEMU 8.2.91 monitor - type 'help' for more information
  (qemu) q

[*] https://lore.kernel.org/qemu-devel/zgqks4rpmst5x...@redhat.com/

Suggested-by: Daniel P. Berrangé 
Signed-off-by: Philippe Mathieu-Daudé 
---
 docs/about/deprecated.rst |  7 +++
 include/hw/i386/pc.h  |  1 +
 hw/i386/pc_piix.c | 14 ++
 3 files changed, 22 insertions(+)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 7b548519b5..345c35507f 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -208,6 +208,13 @@ is no longer packaged in any distro making it harder to 
run the
 ``check-tcg`` tests. Unless we can improve the testing situation there
 is a chance the code will bitrot without anyone noticing.
 
+64-bit (x86_64) CPUs on the ``isapc`` machine (since 9.0)
+'
+
+The ``isapc`` machine aims to emulate old PC machine without PCI was
+generalized, so hardware available around 1995, before 64-bit intel
+CPUs were produced.
+
 System emulator machines
 
 
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 27a68071d7..2d202b9549 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -96,6 +96,7 @@ struct PCMachineClass {
 const char *default_south_bridge;
 
 /* Compat options: */
+bool deprecate_64bit_cpu; /* Specific to the 'isapc' machine */
 
 /* Default CPU model version.  See x86_cpu_set_default_version(). */
 int default_cpu_version;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 18ba076609..2e5b2efc33 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -182,7 +182,20 @@ static void pc_init1(MachineState *machine, const char 
*pci_type)
 }
 
 pc_machine_init_sgx_epc(pcms);
+
 x86_cpus_init(x86ms, pcmc->default_cpu_version);
+if (pcmc->deprecate_64bit_cpu) {
+X86CPU *cpu = X86_CPU(first_cpu);
+
+if (cpu->env.features[FEAT_8000_0001_EDX] & CPUID_EXT2_LM) {
+const char *cpu_type = object_get_typename(OBJECT(first_cpu));
+int cpu_len = strlen(cpu_type) - strlen(X86_CPU_TYPE_SUFFIX);
+
+warn_report("Use of 64-bit CPU '%.*s' is deprecated"
+" on the ISA-only PC machine",
+cpu_len, cpu_type);
+}
+}
 
 if (kvm_enabled()) {
 kvmclock_create(pcmc->kvmclock_create_always);
@@ -918,6 +931,7 @@ static void isapc_machine_options(MachineClass *m)
 pcmc->gigabyte_align = false;
 pcmc->smbios_legacy_mode = true;
 pcmc->has_reserved_memory = false;
+pcmc->deprecate_64bit_cpu = true;
 m->default_nic = "ne2k_isa";
 m->default_cpu_type = X86_CPU_TYPE_NAME("486");
 m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[RFC PATCT 2/2] TODO virNodeDeviceUpdateCaps: checks missing?

2024-03-27 Thread Marc Hartmayer
I'm not familiar with the code so I cannot decide if ignoring the return values
is a bug or not. At least, it looks awkward and should be annotated.

Signed-off-by: Marc Hartmayer 
---
 src/conf/node_device_conf.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c
index c146a9f0c881..2f9abf5d9938 100644
--- a/src/conf/node_device_conf.c
+++ b/src/conf/node_device_conf.c
@@ -2646,11 +2646,13 @@ virNodeDeviceUpdateCaps(virNodeDeviceDef *def)
 while (cap) {
 switch (cap->data.type) {
 case VIR_NODE_DEV_CAP_SCSI_HOST:
-virNodeDeviceGetSCSIHostCaps(>data.scsi_host);
+if (virNodeDeviceGetSCSIHostCaps(>data.scsi_host) < 0)
+return -1;
 break;
 case VIR_NODE_DEV_CAP_SCSI_TARGET:
-virNodeDeviceGetSCSITargetCaps(def->sysfs_path,
-   >data.scsi_target);
+if (virNodeDeviceGetSCSITargetCaps(def->sysfs_path,
+   >data.scsi_target) < 0)
+return -1;
 break;
 case VIR_NODE_DEV_CAP_NET:
 if (virNetDevGetLinkInfo(cap->data.net.ifname,
-- 
2.34.1
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[RFC PATCH 1/2] node_device_conf: virNodeDeviceGetSCSITargetCaps: fix memory leak

2024-03-27 Thread Marc Hartmayer
Make sure the old value in `scsi_target->wwpn` is free'd before replacing it.
While at it, simplify the code.

==9104== 38 bytes in 2 blocks are definitely lost in loss record 1,943 of 3,250
==9104==at 0x483B8C0: malloc (vg_replace_malloc.c:442)
==9104==by 0x4DFB69B: g_malloc (gmem.c:130)
==9104==by 0x4E1921D: g_strdup (gstrfuncs.c:363)
==9104==by 0x495D60B: g_strdup_inline (gstrfuncs.h:321)
==9104==by 0x495D60B: virFCReadRportValue (virfcp.c:62)
==9104==by 0x4A5F5CB: virNodeDeviceGetSCSITargetCaps 
(node_device_conf.c:2914)
==9104==by 0xBF62529: udevProcessSCSITarget (node_device_udev.c:657)
==9104==by 0xBF62529: udevGetDeviceDetails (node_device_udev.c:1406)
==9104==by 0xBF62529: udevAddOneDevice (node_device_udev.c:1563)
==9104==by 0xBF639B5: udevProcessDeviceListEntry (node_device_udev.c:1637)
==9104==by 0xBF639B5: udevEnumerateDevices (node_device_udev.c:1691)
==9104==by 0xBF639B5: nodeStateInitializeEnumerate (node_device_udev.c:2009)
==9104==by 0x49BDBFD: virThreadHelper (virthread.c:256)
==9104==by 0x5242069: start_thread (in /usr/lib64/libc.so.6)

Signed-off-by: Marc Hartmayer 
---
 src/conf/node_device_conf.c | 29 +++--
 1 file changed, 11 insertions(+), 18 deletions(-)

diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c
index 48140b17baa5..c146a9f0c881 100644
--- a/src/conf/node_device_conf.c
+++ b/src/conf/node_device_conf.c
@@ -2894,9 +2894,9 @@ int
 virNodeDeviceGetSCSITargetCaps(const char *sysfsPath,
virNodeDevCapSCSITarget *scsi_target)
 {
-int ret = -1;
 g_autofree char *dir = NULL;
 g_autofree char *rport = NULL;
+g_autofree char *wwpn = NULL;
 
 VIR_DEBUG("Checking if '%s' is an FC remote port", scsi_target->name);
 
@@ -2906,28 +2906,21 @@ virNodeDeviceGetSCSITargetCaps(const char *sysfsPath,
 rport = g_path_get_basename(dir);
 
 if (!virFCIsCapableRport(rport))
-goto cleanup;
+return -1;
+
+if (virFCReadRportValue(rport, "port_name",
+) < 0) {
+VIR_WARN("Failed to read port_name for '%s'", rport);
+return -1;
+}
 
 VIR_FREE(scsi_target->rport);
 scsi_target->rport = g_steal_pointer();
 
-if (virFCReadRportValue(scsi_target->rport, "port_name",
-_target->wwpn) < 0) {
-VIR_WARN("Failed to read port_name for '%s'", scsi_target->rport);
-goto cleanup;
-}
-
+VIR_FREE(scsi_target->wwpn);
+scsi_target->wwpn = g_steal_pointer();
 scsi_target->flags |= VIR_NODE_DEV_CAP_FLAG_FC_RPORT;
-ret = 0;
-
- cleanup:
-if (ret < 0) {
-VIR_FREE(scsi_target->rport);
-VIR_FREE(scsi_target->wwpn);
-scsi_target->flags &= ~VIR_NODE_DEV_CAP_FLAG_FC_RPORT;
-}
-
-return ret;
+return 0;
 }
 
 
-- 
2.34.1
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH for 10.2.0 0/3] Fix spurious error from PCI VPD parsing

2024-03-27 Thread Ján Tomko

On a Wednesday in 2024, Peter Krempa wrote:

Multiple people complained, let's fix it for the next release.

Peter Krempa (3):
 virpcivpd: Revert error reporting from PCI VPD parser
 pci: Remove error reporting from PCI VPD parsing
 NEWS: Mention fix for PCI VPD error reporting

NEWS.rst| 11 
po/POTFILES |  1 -
src/conf/node_device_conf.c | 13 --
src/libvirt_private.syms|  1 -
src/util/virpci.c   | 35 ++
src/util/virpci.h   |  1 -
src/util/virpcivpd.c| 50 +++--
7 files changed, 43 insertions(+), 69 deletions(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: PGP signature
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH 2/3] pci: Remove error reporting from PCI VPD parsing

2024-03-27 Thread Ján Tomko

On a Wednesday in 2024, Peter Krempa wrote:

The PCI VPD (Vital Product Data) may be missing or the kernel can report
presence but not actually have the data. Also the data is specified by
the device vendor and thus may be invalid in some cases.

To avoid log spamming, since the only usage in the node device driver is
ignoring errors, remove all error reporting.

Closes: https://gitlab.com/libvirt/libvirt/-/issues/607
Signed-off-by: Peter Krempa 
---
src/conf/node_device_conf.c | 13 +---
src/libvirt_private.syms|  1 -
src/util/virpci.c   | 41 +++--
src/util/virpci.h   |  1 -
4 files changed, 12 insertions(+), 44 deletions(-)

diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c
index 48140b17ba..32b69aae84 100644
--- a/src/conf/node_device_conf.c
+++ b/src/conf/node_device_conf.c
@@ -3104,26 +3094,16 @@ virPCIVPDResource *
virPCIDeviceGetVPD(virPCIDevice *dev)
{
g_autofree char *vpdPath = virPCIFile(dev->name, "vpd");
-virPCIVPDResource *ret = NULL;
VIR_AUTOCLOSE fd = -1;

-if (!virPCIDeviceHasVPD(dev)) {
-virReportError(VIR_ERR_INTERNAL_ERROR, _("Device %1$s does not have a 
VPD"),
-   virPCIDeviceGetName(dev));
-return NULL;
-}
+fd = open(vpdPath, O_RDONLY);

-if ((fd = open(vpdPath, O_RDONLY)) < 0) {
-virReportSystemError(errno, _("Failed to open a VPD file '%1$s'"), 
vpdPath);
-return NULL;
-}
+VIR_DEBUG("dev='%s' path='%s' fd='%d'", virPCIDeviceGetName(dev), vpdPath, 
fd);

-if (!(ret = virPCIVPDParse(fd))) {
-virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Failed to parse device VPD 
data"));
-return NULL;
-}
+if (fd < 0)
+return 0;


This function returns a pointer. s/0/NULL/



-return ret;
+return virPCIVPDParse(fd);
}

#else


signature.asc
Description: PGP signature
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH 2/3] pci: Remove error reporting from PCI VPD parsing

2024-03-27 Thread Peter Krempa
The PCI VPD (Vital Product Data) may be missing or the kernel can report
presence but not actually have the data. Also the data is specified by
the device vendor and thus may be invalid in some cases.

To avoid log spamming, since the only usage in the node device driver is
ignoring errors, remove all error reporting.

Closes: https://gitlab.com/libvirt/libvirt/-/issues/607
Signed-off-by: Peter Krempa 
---
 src/conf/node_device_conf.c | 13 +---
 src/libvirt_private.syms|  1 -
 src/util/virpci.c   | 41 +++--
 src/util/virpci.h   |  1 -
 4 files changed, 12 insertions(+), 44 deletions(-)

diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c
index 48140b17ba..32b69aae84 100644
--- a/src/conf/node_device_conf.c
+++ b/src/conf/node_device_conf.c
@@ -3066,15 +3066,12 @@ virNodeDeviceGetPCIVPDDynamicCap(virNodeDevCapPCIDev 
*devCapPCIDev)
 if (!(pciDev = virPCIDeviceNew()))
 return -1;

-if (virPCIDeviceHasVPD(pciDev)) {
-/* VPD is optional in PCI(e) specs. If it is there, attempt to add it. 
*/
-if ((res = virPCIDeviceGetVPD(pciDev))) {
-devCapPCIDev->flags |= VIR_NODE_DEV_CAP_FLAG_PCI_VPD;
-devCapPCIDev->vpd = g_steal_pointer();
-} else {
-virResetLastError();
-}
+/* VPD is optional in PCI(e) specs. If it is there, attempt to add it. */
+if ((res = virPCIDeviceGetVPD(pciDev))) {
+devCapPCIDev->flags |= VIR_NODE_DEV_CAP_FLAG_PCI_VPD;
+devCapPCIDev->vpd = g_steal_pointer();
 }
+
 return 0;
 }

diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 6b6bcc368a..84e30b711c 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -3107,7 +3107,6 @@ virPCIDeviceGetUnbindFromStub;
 virPCIDeviceGetUsedBy;
 virPCIDeviceGetVPD;
 virPCIDeviceHasPCIExpressLink;
-virPCIDeviceHasVPD;
 virPCIDeviceIsAssignable;
 virPCIDeviceIsPCIExpress;
 virPCIDeviceListAdd;
diff --git a/src/util/virpci.c b/src/util/virpci.c
index 8becec4aa5..1582c8b9ab 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -3078,24 +3078,14 @@ virPCIGetVirtualFunctionInfo(const char 
*vf_sysfs_device_path,
 }


-bool
-virPCIDeviceHasVPD(virPCIDevice *dev)
-{
-g_autofree char *vpdPath = virPCIFile(dev->name, "vpd");
-bool ret = virFileIsRegular(vpdPath);
-
-VIR_DEBUG("path='%s', exists='%d'", vpdPath, ret);
-
-return ret;
-}
-
 /**
  * virPCIDeviceGetVPD:
  * @dev: a PCI device to get a PCI VPD for.
  *
  * Obtain a PCI device's Vital Product Data (VPD). VPD is optional in
  * both PCI Local Bus and PCIe specifications so there is no guarantee it
- * will be there for a particular device.
+ * will be there for a particular device. The VPD data is returned in @vpd if
+ * it's available or otherwise NULL is set.
  *
  * Returns: a pointer to virPCIVPDResource which needs to be freed by the 
caller
  * or NULL if getting it failed for some reason (e.g. invalid format, I/O 
error).
@@ -3104,26 +3094,16 @@ virPCIVPDResource *
 virPCIDeviceGetVPD(virPCIDevice *dev)
 {
 g_autofree char *vpdPath = virPCIFile(dev->name, "vpd");
-virPCIVPDResource *ret = NULL;
 VIR_AUTOCLOSE fd = -1;

-if (!virPCIDeviceHasVPD(dev)) {
-virReportError(VIR_ERR_INTERNAL_ERROR, _("Device %1$s does not have a 
VPD"),
-   virPCIDeviceGetName(dev));
-return NULL;
-}
+fd = open(vpdPath, O_RDONLY);

-if ((fd = open(vpdPath, O_RDONLY)) < 0) {
-virReportSystemError(errno, _("Failed to open a VPD file '%1$s'"), 
vpdPath);
-return NULL;
-}
+VIR_DEBUG("dev='%s' path='%s' fd='%d'", virPCIDeviceGetName(dev), vpdPath, 
fd);

-if (!(ret = virPCIVPDParse(fd))) {
-virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Failed to parse device 
VPD data"));
-return NULL;
-}
+if (fd < 0)
+return 0;

-return ret;
+return virPCIVPDParse(fd);
 }

 #else
@@ -3200,17 +3180,10 @@ virPCIGetVirtualFunctionInfo(const char 
*vf_sysfs_device_path G_GNUC_UNUSED,
 return -1;
 }

-bool
-virPCIDeviceHasVPD(virPCIDevice *dev G_GNUC_UNUSED)
-{
-virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _(unsupported));
-return NULL;
-}

 virPCIVPDResource *
 virPCIDeviceGetVPD(virPCIDevice *dev G_GNUC_UNUSED)
 {
-virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _(unsupported));
 return NULL;
 }
 #endif /* __linux__ */
diff --git a/src/util/virpci.h b/src/util/virpci.h
index a5bfe9c35d..ba5e0ae6f1 100644
--- a/src/util/virpci.h
+++ b/src/util/virpci.h
@@ -270,7 +270,6 @@ int virPCIGetVirtualFunctionInfo(const char 
*vf_sysfs_device_path,
  char **pfname,
  int *vf_index);

-bool virPCIDeviceHasVPD(virPCIDevice *dev);
 virPCIVPDResource * virPCIDeviceGetVPD(virPCIDevice *dev);

 int virPCIDeviceUnbind(virPCIDevice *dev);
-- 
2.44.0
___
Devel mailing list -- 

[PATCH 3/3] NEWS: Mention fix for PCI VPD error reporting

2024-03-27 Thread Peter Krempa
Signed-off-by: Peter Krempa 
---
 NEWS.rst | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/NEWS.rst b/NEWS.rst
index ef9e312698..05fd9e3194 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -52,6 +52,17 @@ v10.2.0 (unreleased)
 releases to 10.2.0 works as well, but the other direction remains broken
 unless the fix is backported.

+  * node_device: Don't report spurious errors from PCI VPD parsing
+
+In last release the PCI Vital Product Data parser was enhanced to report
+errors but that effort failed as some kernels have the file but don't allow
+reading it causing logs to be spammed with::
+
+  libvirtd[21055]: operation failed: failed to read the PCI VPD data
+
+Since the data is used only in the node device XML and errors are ignored 
if
+the parsing failed, this release removes all the error reporting.
+

 v10.1.0 (2024-03-01)
 
-- 
2.44.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH for 10.2.0 0/3] Fix spurious error from PCI VPD parsing

2024-03-27 Thread Peter Krempa
Multiple people complained, let's fix it for the next release.

Peter Krempa (3):
  virpcivpd: Revert error reporting from PCI VPD parser
  pci: Remove error reporting from PCI VPD parsing
  NEWS: Mention fix for PCI VPD error reporting

 NEWS.rst| 11 
 po/POTFILES |  1 -
 src/conf/node_device_conf.c | 13 --
 src/libvirt_private.syms|  1 -
 src/util/virpci.c   | 35 ++
 src/util/virpci.h   |  1 -
 src/util/virpcivpd.c| 50 +++--
 7 files changed, 43 insertions(+), 69 deletions(-)

-- 
2.44.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH 1/3] virpcivpd: Revert error reporting from PCI VPD parser

2024-03-27 Thread Peter Krempa
The VPD parsing is fragile and depends on hardware vendor's adherance to
standards. Since libvirt only ever uses this data to report it in the
nodedev XML which ignores any errors there's no much point in having
error reporting which I've added recently.

Turn the errors into VIR_DEBUG statements in preparation for upcoming
patch which completely removes the expectation to report errors.

This effectively reverts commits dfc85658bd0 and f85a382a0e7.

Signed-off-by: Peter Krempa 
---
 po/POTFILES  |  1 -
 src/util/virpci.c|  8 ++-
 src/util/virpcivpd.c | 50 ++--
 3 files changed, 27 insertions(+), 32 deletions(-)

diff --git a/po/POTFILES b/po/POTFILES
index 428919815d..6fbff4bef2 100644
--- a/po/POTFILES
+++ b/po/POTFILES
@@ -313,7 +313,6 @@ src/util/virnuma.c
 src/util/virnvme.c
 src/util/virobject.c
 src/util/virpci.c
-src/util/virpcivpd.c
 src/util/virperf.c
 src/util/virpidfile.c
 src/util/virpolkit.c
diff --git a/src/util/virpci.c b/src/util/virpci.c
index 780b4f9eec..8becec4aa5 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -3104,6 +3104,7 @@ virPCIVPDResource *
 virPCIDeviceGetVPD(virPCIDevice *dev)
 {
 g_autofree char *vpdPath = virPCIFile(dev->name, "vpd");
+virPCIVPDResource *ret = NULL;
 VIR_AUTOCLOSE fd = -1;

 if (!virPCIDeviceHasVPD(dev)) {
@@ -3117,7 +3118,12 @@ virPCIDeviceGetVPD(virPCIDevice *dev)
 return NULL;
 }

-return virPCIVPDParse(fd);
+if (!(ret = virPCIVPDParse(fd))) {
+virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Failed to parse device 
VPD data"));
+return NULL;
+}
+
+return ret;
 }

 #else
diff --git a/src/util/virpcivpd.c b/src/util/virpcivpd.c
index 16df468875..02d405f038 100644
--- a/src/util/virpcivpd.c
+++ b/src/util/virpcivpd.c
@@ -361,9 +361,9 @@ virPCIVPDResourceUpdateKeyword(virPCIVPDResource *res,
  * @offset: The offset at which bytes need to be read.
  * @csum: A pointer to a byte containing the current checksum value. Mutated 
by this function.
  *
- * Returns 0 if exactly @count bytes were read from @vpdFileFd. The csum value 
is
- * also modified as bytes are read. If an error occurs while reading data from 
the VPD file
- * descriptor, it is reported and -1 is returned to the caller.
+ * Returns 0 if exactly @count bytes were read from @vpdFileFd. The csum value
+ * is also modified as bytes are read. If an error occurs while reading data
+ * from the VPD file descriptor -1 is returned to the caller.
  */
 static int
 virPCIVPDReadVPDBytes(int vpdFileFd,
@@ -375,8 +375,7 @@ virPCIVPDReadVPDBytes(int vpdFileFd,
 ssize_t numRead = pread(vpdFileFd, buf, count, offset);

 if (numRead != count) {
-virReportError(VIR_ERR_OPERATION_FAILED, "%s",
-   _("failed to read the PCI VPD data"));
+VIR_DEBUG("read='%zd' expected='%zu'", numRead, count);
 return -1;
 }

@@ -447,8 +446,7 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd,

 case VIR_PCI_VPD_RESOURCE_FIELD_VALUE_FORMAT_RDWR:
 if (readOnly) {
-virReportError(VIR_ERR_OPERATION_FAILED, "%s",
-   _("failed to read the PCI VPD data: 
unexpected RW keyword in read-only section"));
+VIR_DEBUG("unexpected RW keyword in read-only section");
 return -1;
 }

@@ -457,8 +455,7 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd,

 case VIR_PCI_VPD_RESOURCE_FIELD_VALUE_FORMAT_RESVD:
 if (!readOnly) {
-virReportError(VIR_ERR_OPERATION_FAILED, "%s",
-   _("failed to read the PCI VPD data: 
unexpected RV keyword in read-write section"));
+VIR_DEBUG("unexpected RV keyword in read-write section");
 return -1;
 }
 /* Only need one byte to be read and accounted towards
@@ -477,8 +474,7 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd,
 if (resPos + resDataLen < fieldPos + fieldDataLen) {
 /* In this case the field cannot simply be skipped since the 
position of the
  * next field is determined based on the length of a previous 
field. */
-virReportError(VIR_ERR_OPERATION_FAILED, "%s",
-   _("failed to read the PCI VPD data: data field 
length invalid"));
+VIR_DEBUG("data field length invalid");
 return -1;
 }

@@ -517,8 +513,7 @@ virPCIVPDParseVPDLargeResourceFields(int vpdFileFd,
 case VIR_PCI_VPD_RESOURCE_FIELD_VALUE_FORMAT_RESVD:
 if (*csum) {
 /* All bytes up to and including the checksum byte should 
add up to 0. */
-virReportError(VIR_ERR_OPERATION_FAILED, "%s",
-   _("failed to read the PCI VPD data: invalid 
checksum"));
+

Re: [PATCH-for-9.0] hw/i386/pc: Deprecate 64-bit CPUs on ISA-only PC machine

2024-03-27 Thread Daniel P . Berrangé
On Wed, Mar 27, 2024 at 04:35:17PM +0100, Philippe Mathieu-Daudé wrote:
> Per Daniel suggestion [*]:
> 
>  > isapc could arguably be restricted to just 32-bit CPU models,
>  > because we should not need it to support any feature that didn't
>  > exist prior to circa 1995. eg refuse to start with isapc, if 'lm'
>  > is present in the CPU model for example.
> 
> [*] https://lore.kernel.org/qemu-devel/zgqks4rpmst5x...@redhat.com/
> 
> Suggested-by: Daniel P. Berrangé 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  docs/about/deprecated.rst | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 7b548519b5..345c35507f 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -208,6 +208,13 @@ is no longer packaged in any distro making it harder to 
> run the
>  ``check-tcg`` tests. Unless we can improve the testing situation there
>  is a chance the code will bitrot without anyone noticing.
>  
> +64-bit (x86_64) CPUs on the ``isapc`` machine (since 9.0)
> +'
> +
> +The ``isapc`` machine aims to emulate old PC machine without PCI was
> +generalized, so hardware available around 1995, before 64-bit intel
> +CPUs were produced.
> +
>  System emulator machines
>  

I would expect there to be a 'warn_report()' added to the isapc
init code somewhere to go along with this, that will later be
turned into an 'error_report' once the deprecation period is
over.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH 2/3] nodedev: immediate update of active config on udev add

2024-03-27 Thread Jonathon Jongsma

On 3/20/24 10:46 AM, Boris Fiuczynski wrote:

When an udev add event occurs the mdev active config data requires an
update via mdevctl as the udev does not contain all config data.
This update needs to occur immediate and to be finished before the
libvirt CREATE event is issued to keep the API usage reliable.


The problem that you're trying to solve isn't spelled out very 
explicitly here. My understanding is that the issue occurs when you 
start a mediated device that has attributes (and the device is supported 
by callout scripts in mdevctl). With the current code, my assumption is 
that we observe the following behavior:

- udev event is emitted
- libvirt handles the udev event and emits a 
VIR_NODE_DEVICE_EVENT_CREATED event for the new mdev. At this point the 
mdev only information that is provided by udev (such as uuid, mdev type) 
and doesn't include any attributes, for example.
- we schedule a thread to query mdevctl for the full information for the 
device. The mdev device gets update to include the full mdevctl data, 
including attributes
- libvirt emits a VIR_NODE_DEVICE_EVENT_ID_UPDATE event to indicate that 
the device information was updated


And you're trying to skip the last step and make sure that the 
attributes are set at the time that the first CREATED event is emitted. 
Correct? Or is the behavior you're seeing different than what I've 
described?




Signed-off-by: Boris Fiuczynski 
---
  src/node_device/node_device_udev.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/src/node_device/node_device_udev.c 
b/src/node_device/node_device_udev.c
index 4730a5b986..0f335df950 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -1606,6 +1606,12 @@ udevAddOneDevice(struct udev_device *device)
  if (has_mdev_types)
  scheduleMdevctlUpdate(driver->privateData, false);
  
+/* The added mdev needs an immediate active config update before

+ * the event is issues to allow sane API usage. */
+if (is_mdev && (nodeDeviceUpdateMediatedDevices() < 0))
+VIR_WARN("Update of mediated device %s failed",
+ def ? NULLSTR(def->sysfs_path) : "");
+
  ret = 0;
  
   cleanup:

``

Right now libvirt has a dedicated thread for handling udev updates, and 
we also spawn a separate thread to query mdevctl whenever we detect that 
mdev state has changed. This patch makes it so that mdevctl is now 
executed directly from the udev thread, which changes that separation of 
responsibilities. It shouldn't cause any memory corruption since 
nodeDeviceUpdateMediatedDevices() is already threadsafe, but it makes 
the code harder to reason about. When we introduced mdevctl support to 
libvirt, the first versions of my patch series did in fact query mdevctl 
from the udev thread. But based on concerns during code review, it was 
moved out to a separate thread. So I don't think that we should 
necessarily reintroduce that here.


In addition, I notice that udevHandleOneDevice() already schedules an 
mdevctl update thread to be run after this function (udevAddOneDevice()) 
is called for a mediated device. So after this patch, a new udev event 
for a mediated device would result in the udev thread querying mdevctl 
immediately and then also spawning a new thread to query mdevctl.


Jonathon
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH-for-9.0? v2 1/3] fpu/softfloat: Remove mention of TILE-Gx target

2024-03-27 Thread Thomas Huth

On 27/03/2024 15.48, Philippe Mathieu-Daudé wrote:

TILE-Gx has been removed during the v6.0 release (see
commit 2cc1a90166 "Remove deprecated target tilegx"),
no need to mention it in the list of "supported targets".

Signed-off-by: Philippe Mathieu-Daudé 
---
  fpu/softfloat-specialize.c.inc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fpu/softfloat-specialize.c.inc b/fpu/softfloat-specialize.c.inc
index 1610472cfc..1c85c48a73 100644
--- a/fpu/softfloat-specialize.c.inc
+++ b/fpu/softfloat-specialize.c.inc
@@ -152,7 +152,7 @@ static void parts64_default_nan(FloatParts64 *p, 
float_status *status)
  /*
   * This case is true for Alpha, ARM, MIPS, OpenRISC, PPC, RISC-V,
   * S390, SH4, TriCore, and Xtensa.  Our other supported targets,
- * CRIS, Nios2, and Tile, do not have floating-point.
+ * CRIS and Nios2, do not have floating-point.
   */
  if (snan_bit_is_one(status)) {
  /* set all bits other than msb */


Reviewed-by: Thomas Huth 
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH-for-9.1] target/nios2: Remove machines and system emulation

2024-03-27 Thread Thomas Huth

On 27/03/2024 15.15, Philippe Mathieu-Daudé wrote:

On 27/3/24 14:19, Thomas Huth wrote:

On 27/03/2024 13.45, Philippe Mathieu-Daudé wrote:

On 27/3/24 13:35, Philippe Mathieu-Daudé wrote:

Remove the Nios II machines and the system emulation code
(deprecated since v8.2 in commit 9997771bc1 "target/nios2:
Deprecate the Nios II architecture").


Please remind me, why didn't we deprecate the linux-user emulation, too?


Hmm I think we actually did (overall target), since there is
an issue with signals.


The placement in the deprecated.rst file seems a bit unfortunate in that 
case, since the subchapter is called "System emulator CPUs" ?


Anyway, I just saw your v2, so let's continue discussion there...


diff --git a/hw/nios2/Kconfig b/hw/nios2/Kconfig
deleted file mode 100644
index 4748ae27b6..00
--- a/hw/nios2/Kconfig
+++ /dev/null
@@ -1,13 +0,0 @@
-config NIOS2_10M50
-    bool
-    select NIOS2
-    select SERIAL
-    select ALTERA_TIMER


I forgot to mention I deliberately chose to keep the Altera
timer model in the tree, since it looks like a re-usable
IP component.


But if it is not used anymore by any machine, this will happily bitrot, 
won't it? I think I'd rather remove it, too ... maybe in a separate patch, 
so that in case somebody later needs it again, it can be restored by 
simply reverting the patch again.


It is related to dynamic machines, how do we decide what components
to remove once there? I suppose we'd need to deprecate every single
component, like ALTERA_TIMER. But we are not yet generating dynamic
machines, so for now we can consider ALTERA_TIMER part of Nios II
sysemu removal. I like your idea of removing it as a separate patch.


Even if we switch to dynamic machines one day, the devices still need to be 
somehow used and tested in the CI, e.g. by scripts that assemble a machine 
dynamically. If there's a device that is never used at all, we can also 
simply remove it until someone needs it again, I think.


 Thomas

___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.0] hw/i386/pc: Deprecate 64-bit CPUs on ISA-only PC machine

2024-03-27 Thread Philippe Mathieu-Daudé
Per Daniel suggestion [*]:

 > isapc could arguably be restricted to just 32-bit CPU models,
 > because we should not need it to support any feature that didn't
 > exist prior to circa 1995. eg refuse to start with isapc, if 'lm'
 > is present in the CPU model for example.

[*] https://lore.kernel.org/qemu-devel/zgqks4rpmst5x...@redhat.com/

Suggested-by: Daniel P. Berrangé 
Signed-off-by: Philippe Mathieu-Daudé 
---
 docs/about/deprecated.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 7b548519b5..345c35507f 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -208,6 +208,13 @@ is no longer packaged in any distro making it harder to 
run the
 ``check-tcg`` tests. Unless we can improve the testing situation there
 is a chance the code will bitrot without anyone noticing.
 
+64-bit (x86_64) CPUs on the ``isapc`` machine (since 9.0)
+'
+
+The ``isapc`` machine aims to emulate old PC machine without PCI was
+generalized, so hardware available around 1995, before 64-bit intel
+CPUs were produced.
+
 System emulator machines
 
 
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[libvirt PATCH] NEWS: Update

2024-03-27 Thread Ján Tomko
Update NEWS with new news.

Signed-off-by: Ján Tomko 
---
 NEWS.rst | 21 +
 1 file changed, 21 insertions(+)

diff --git a/NEWS.rst b/NEWS.rst
index ef9e312698..ce83ee629f 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -36,6 +36,13 @@ v10.2.0 (unreleased)
 use the upcoming QEMU 9.0.0 release together with the development version
 of edk2.
 
+  * qemu: Introduce virDomainGraphicsReload API
+
+Reloading the graphics display is now supported for QEMU guests using
+VNC. This is useful to make QEMU reload the TLS certificats without
+restarting the guest. Available via the `virDomainGraphicsReload` API
+and the `domdisplay-reload` virsh command.
+
 * **Improvements**
 
 * **Bug fixes**
@@ -52,6 +59,20 @@ v10.2.0 (unreleased)
 releases to 10.2.0 works as well, but the other direction remains broken
 unless the fix is backported.
 
+  * qemu: set correct SELinux label for unprivileged virtiofsd
+
+Now, it's possible to use virtiofsd-based `` shares even
+if the guest is confined using SELinux.
+
+  * qemu: fix a crash on unprivileged virtiofsd hotplug
+
+Hotplugging virtiofsd-based filesystems works now.
+
+  * virt-admin: Fix segfault when libvirtd dies
+
+Now, `virt-admin` no longer crashes when `libvirtd` unexpectedly closes
+the connection.
+
 
 v10.1.0 (2024-03-01)
 
-- 
2.44.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 3/3] hw/timer: Remove the ALTERA_TIMER model

2024-03-27 Thread Philippe Mathieu-Daudé
The ALTERA_TIMER was only used by Nios II machines,
which have been removed. Since it has no direct user,
remove it.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/timer/altera_timer.c | 244 
 hw/timer/Kconfig|   4 -
 hw/timer/meson.build|   1 -
 3 files changed, 249 deletions(-)
 delete mode 100644 hw/timer/altera_timer.c

diff --git a/hw/timer/altera_timer.c b/hw/timer/altera_timer.c
deleted file mode 100644
index 0f1f54206a..00
--- a/hw/timer/altera_timer.c
+++ /dev/null
@@ -1,244 +0,0 @@
-/*
- * QEMU model of the Altera timer.
- *
- * Copyright (c) 2012 Chris Wulff 
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, see
- * 
- */
-
-#include "qemu/osdep.h"
-#include "qemu/module.h"
-#include "qapi/error.h"
-
-#include "hw/sysbus.h"
-#include "hw/irq.h"
-#include "hw/ptimer.h"
-#include "hw/qdev-properties.h"
-#include "qom/object.h"
-
-#define R_STATUS  0
-#define R_CONTROL 1
-#define R_PERIODL 2
-#define R_PERIODH 3
-#define R_SNAPL   4
-#define R_SNAPH   5
-#define R_MAX 6
-
-#define STATUS_TO 0x0001
-#define STATUS_RUN0x0002
-
-#define CONTROL_ITO   0x0001
-#define CONTROL_CONT  0x0002
-#define CONTROL_START 0x0004
-#define CONTROL_STOP  0x0008
-
-#define TYPE_ALTERA_TIMER "ALTR.timer"
-OBJECT_DECLARE_SIMPLE_TYPE(AlteraTimer, ALTERA_TIMER)
-
-struct AlteraTimer {
-SysBusDevice  busdev;
-MemoryRegion  mmio;
-qemu_irq  irq;
-uint32_t  freq_hz;
-ptimer_state *ptimer;
-uint32_t  regs[R_MAX];
-};
-
-static int timer_irq_state(AlteraTimer *t)
-{
-bool irq = (t->regs[R_STATUS] & STATUS_TO) &&
-   (t->regs[R_CONTROL] & CONTROL_ITO);
-return irq;
-}
-
-static uint64_t timer_read(void *opaque, hwaddr addr,
-   unsigned int size)
-{
-AlteraTimer *t = opaque;
-uint64_t r = 0;
-
-addr >>= 2;
-
-switch (addr) {
-case R_CONTROL:
-r = t->regs[R_CONTROL] & (CONTROL_ITO | CONTROL_CONT);
-break;
-
-default:
-if (addr < ARRAY_SIZE(t->regs)) {
-r = t->regs[addr];
-}
-break;
-}
-
-return r;
-}
-
-static void timer_write(void *opaque, hwaddr addr,
-uint64_t value, unsigned int size)
-{
-AlteraTimer *t = opaque;
-uint64_t tvalue;
-uint32_t count = 0;
-int irqState = timer_irq_state(t);
-
-addr >>= 2;
-
-switch (addr) {
-case R_STATUS:
-/* The timeout bit is cleared by writing the status register. */
-t->regs[R_STATUS] &= ~STATUS_TO;
-break;
-
-case R_CONTROL:
-ptimer_transaction_begin(t->ptimer);
-t->regs[R_CONTROL] = value & (CONTROL_ITO | CONTROL_CONT);
-if ((value & CONTROL_START) &&
-!(t->regs[R_STATUS] & STATUS_RUN)) {
-ptimer_run(t->ptimer, 1);
-t->regs[R_STATUS] |= STATUS_RUN;
-}
-if ((value & CONTROL_STOP) && (t->regs[R_STATUS] & STATUS_RUN)) {
-ptimer_stop(t->ptimer);
-t->regs[R_STATUS] &= ~STATUS_RUN;
-}
-ptimer_transaction_commit(t->ptimer);
-break;
-
-case R_PERIODL:
-case R_PERIODH:
-ptimer_transaction_begin(t->ptimer);
-t->regs[addr] = value & 0x;
-if (t->regs[R_STATUS] & STATUS_RUN) {
-ptimer_stop(t->ptimer);
-t->regs[R_STATUS] &= ~STATUS_RUN;
-}
-tvalue = (t->regs[R_PERIODH] << 16) | t->regs[R_PERIODL];
-ptimer_set_limit(t->ptimer, tvalue + 1, 1);
-ptimer_transaction_commit(t->ptimer);
-break;
-
-case R_SNAPL:
-case R_SNAPH:
-count = ptimer_get_count(t->ptimer);
-t->regs[R_SNAPL] = count & 0x;
-t->regs[R_SNAPH] = count >> 16;
-break;
-
-default:
-break;
-}
-
-if (irqState != timer_irq_state(t)) {
-qemu_set_irq(t->irq, timer_irq_state(t));
-}
-}
-
-static const MemoryRegionOps timer_ops = {
-.read = timer_read,
-.write = timer_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
-.valid = {
-.min_access_size = 1,
-.max_access_size = 4
-}
-};
-
-static void timer_hit(void *opaque)
-{
-AlteraTimer *t = opaque;
-const uint64_t tvalue = (t->regs[R_PERIODH] << 16) | t->regs[R_PERIODL];
-
-t->regs[R_STATUS] |= 

[PATCH-for-9.0? v2 1/3] fpu/softfloat: Remove mention of TILE-Gx target

2024-03-27 Thread Philippe Mathieu-Daudé
TILE-Gx has been removed during the v6.0 release (see
commit 2cc1a90166 "Remove deprecated target tilegx"),
no need to mention it in the list of "supported targets".

Signed-off-by: Philippe Mathieu-Daudé 
---
 fpu/softfloat-specialize.c.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fpu/softfloat-specialize.c.inc b/fpu/softfloat-specialize.c.inc
index 1610472cfc..1c85c48a73 100644
--- a/fpu/softfloat-specialize.c.inc
+++ b/fpu/softfloat-specialize.c.inc
@@ -152,7 +152,7 @@ static void parts64_default_nan(FloatParts64 *p, 
float_status *status)
 /*
  * This case is true for Alpha, ARM, MIPS, OpenRISC, PPC, RISC-V,
  * S390, SH4, TriCore, and Xtensa.  Our other supported targets,
- * CRIS, Nios2, and Tile, do not have floating-point.
+ * CRIS and Nios2, do not have floating-point.
  */
 if (snan_bit_is_one(status)) {
 /* set all bits other than msb */
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 0/3] target/nios2: Remove the deprecated Nios II target

2024-03-27 Thread Philippe Mathieu-Daudé
Since v1:
- Remove user emulation too
- Remove ALTERA_TIMER

Philippe Mathieu-Daudé (3):
  fpu/softfloat: Remove mention of TILE-Gx target
  target/nios2: Remove the deprecated Nios II target
  hw/timer: Remove the ALTERA_TIMER model

 MAINTAINERS   |   13 -
 docs/about/deprecated.rst |   11 -
 docs/about/emulation.rst  |7 -
 docs/about/removed-features.rst   |   14 +
 docs/system/replay.rst|2 +-
 docs/user/main.rst|4 -
 configure |2 -
 configs/devices/nios2-softmmu/default.mak |6 -
 configs/targets/nios2-linux-user.mak  |1 -
 configs/targets/nios2-softmmu.mak |2 -
 meson.build   |2 -
 qapi/machine.json |2 +-
 hw/nios2/boot.h   |   10 -
 include/disas/dis-asm.h   |5 -
 include/exec/poison.h |2 -
 include/exec/user/abitypes.h  |3 +-
 include/hw/intc/nios2_vic.h   |   66 -
 include/sysemu/arch_init.h|1 -
 linux-user/nios2/sockbits.h   |1 -
 linux-user/nios2/syscall_nr.h |  333 --
 linux-user/nios2/target_cpu.h |   49 -
 linux-user/nios2/target_elf.h |   14 -
 linux-user/nios2/target_errno_defs.h  |7 -
 linux-user/nios2/target_fcntl.h   |   11 -
 linux-user/nios2/target_mman.h|   11 -
 linux-user/nios2/target_prctl.h   |1 -
 linux-user/nios2/target_proc.h|1 -
 linux-user/nios2/target_resource.h|1 -
 linux-user/nios2/target_signal.h  |9 -
 linux-user/nios2/target_structs.h |1 -
 linux-user/nios2/target_syscall.h |   37 -
 linux-user/nios2/termbits.h   |1 -
 linux-user/syscall_defs.h |4 +-
 target/nios2/cpu-param.h  |   20 -
 target/nios2/cpu-qom.h|   18 -
 target/nios2/cpu.h|  301 --
 target/nios2/helper.h |   32 -
 target/nios2/mmu.h|   52 -
 tests/tcg/nios2/semicall.h|   28 -
 disas/nios2.c | 3514 -
 hw/intc/nios2_vic.c   |  313 --
 hw/nios2/10m50_devboard.c |  181 -
 hw/nios2/boot.c   |  234 --
 hw/nios2/generic_nommu.c  |  101 -
 hw/timer/altera_timer.c   |  244 --
 linux-user/elfload.c  |   99 -
 linux-user/nios2/cpu_loop.c   |  157 -
 linux-user/nios2/signal.c |  210 -
 target/nios2/cpu.c|  410 --
 target/nios2/helper.c |  371 --
 target/nios2/mmu.c|  216 -
 target/nios2/monitor.c|   35 -
 target/nios2/nios2-semi.c |  230 --
 target/nios2/op_helper.c  |  119 -
 target/nios2/translate.c  | 1107 --
 tests/qtest/machine-none-test.c   |1 -
 fpu/softfloat-specialize.c.inc|2 +-
 .gitlab-ci.d/buildtest.yml|4 +-
 .gitlab-ci.d/crossbuild-template.yml  |2 +-
 .gitlab-ci.d/crossbuilds.yml  |2 +-
 disas/meson.build |1 -
 hw/Kconfig|1 -
 hw/intc/Kconfig   |3 -
 hw/intc/meson.build   |1 -
 hw/meson.build|1 -
 hw/nios2/Kconfig  |   13 -
 hw/nios2/meson.build  |6 -
 hw/timer/Kconfig  |4 -
 hw/timer/meson.build  |1 -
 qemu-options.hx   |8 +-
 scripts/coverity-scan/COMPONENTS.md   |3 -
 scripts/gensyscalls.sh|1 -
 scripts/probe-gdb-support.py  |1 -
 target/Kconfig|1 -
 target/meson.build|1 -
 target/nios2/Kconfig  |3 -
 target/nios2/meson.build  |   17 -
 target/nios2/trace-events |   10 -
 tests/avocado/boot_linux_console.py   |8 -
 tests/avocado/replay_kernel.py|   11 -
 tests/docker/Makefile.include |5 -
 .../debian-nios2-cross.d/build-toolchain.sh   |   87 -
 tests/tcg/nios2/10m50-ghrd.ld |   70 -
 tests/tcg/nios2/Makefile.softmmu-target   |   32 -
 

Re: [PATCH-for-9.1] rdma: Remove RDMA subsystem and pvrdma device

2024-03-27 Thread Fabiano Rosas
Philippe Mathieu-Daudé  writes:

> The whole RDMA subsystem was deprecated in commit e9a54265f5
> ("hw/rdma: Deprecate the pvrdma device and the rdma subsystem")
> released in v8.2. Time to remove it.
>
> Keep the RAM_SAVE_FLAG_HOOK definition since it might appears
> in old migration streams.
>
> Remove the dependencies on libibumad and libibverbs.
>
> Remove the generated vmw_pvrdma/ directory from linux-headers.
>
> Remove RDMA handling from migration.
>
> Remove RDMA handling in GlusterFS block driver.
>
> Remove rdmacm-mux tool from contrib/.
>
> Remove PVRDMA device.
>
> Cc: Peter Xu 
> Cc: Li Zhijian 
> Cc: Yuval Shaia 
> Cc: Marcel Apfelbaum 
> Signed-off-by: Philippe Mathieu-Daudé 

Acked-by: Fabiano Rosas 
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH-for-9.1 v2 10/21] hw/smbios: Remove 'uuid_encoded' argument from smbios_set_defaults()

2024-03-27 Thread Philippe Mathieu-Daudé

On 27/3/24 15:08, Zhao Liu wrote:

On Wed, Mar 27, 2024 at 10:51:12AM +0100, Philippe Mathieu-Daudé wrote:

Date: Wed, 27 Mar 2024 10:51:12 +0100
From: Philippe Mathieu-Daudé 
Subject: [PATCH-for-9.1 v2 10/21] hw/smbios: Remove 'uuid_encoded' argument
  from smbios_set_defaults()
X-Mailer: git-send-email 2.41.0

'uuid_encoded' is always NULL, remove it.


It's a boolean, so,

s/NULL/true/.


Oops, thanks ;)





Signed-off-by: Philippe Mathieu-Daudé 
---
  include/hw/firmware/smbios.h | 3 +--
  hw/arm/virt.c| 3 +--
  hw/i386/fw_cfg.c | 2 +-
  hw/loongarch/virt.c  | 2 +-
  hw/riscv/virt.c  | 2 +-
  hw/smbios/smbios.c   | 6 ++
  6 files changed, 7 insertions(+), 11 deletions(-)


Reviewed-by: Zhao Liu 


___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH-for-9.1] target/nios2: Remove machines and system emulation

2024-03-27 Thread Philippe Mathieu-Daudé

On 27/3/24 14:19, Thomas Huth wrote:

On 27/03/2024 13.45, Philippe Mathieu-Daudé wrote:

On 27/3/24 13:35, Philippe Mathieu-Daudé wrote:

Remove the Nios II machines and the system emulation code
(deprecated since v8.2 in commit 9997771bc1 "target/nios2:
Deprecate the Nios II architecture").


Please remind me, why didn't we deprecate the linux-user emulation, too?


Hmm I think we actually did (overall target), since there is
an issue with signals.


diff --git a/hw/nios2/Kconfig b/hw/nios2/Kconfig
deleted file mode 100644
index 4748ae27b6..00
--- a/hw/nios2/Kconfig
+++ /dev/null
@@ -1,13 +0,0 @@
-config NIOS2_10M50
-    bool
-    select NIOS2
-    select SERIAL
-    select ALTERA_TIMER


I forgot to mention I deliberately chose to keep the Altera
timer model in the tree, since it looks like a re-usable
IP component.


But if it is not used anymore by any machine, this will happily bitrot, 
won't it? I think I'd rather remove it, too ... maybe in a separate 
patch, so that in case somebody later needs it again, it can be restored 
by simply reverting the patch again.


It is related to dynamic machines, how do we decide what components
to remove once there? I suppose we'd need to deprecate every single
component, like ALTERA_TIMER. But we are not yet generating dynamic
machines, so for now we can consider ALTERA_TIMER part of Nios II
sysemu removal. I like your idea of removing it as a separate patch.
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH] security: Ensure kernel/initrd exist before restoring label

2024-03-27 Thread Daniel P . Berrangé
On Mon, Mar 25, 2024 at 07:13:05PM -0600, Jim Fehlig wrote:
> On 3/21/24 08:57, Daniel P. Berrangé wrote:
> > On Fri, Mar 08, 2024 at 04:26:27PM -0700, Jim Fehlig wrote:
> > > When performing an install, it's common for tooling such as virt-install
> > > to remove the install kernel/initrd once they are successfully booted and
> > > the domain has been redefined to boot without them. After the installation
> > > is complete and the domain is rebooted/shutdown, the DAC and selinux
> > > security drivers attempt to restore labels on the now deleted files. It's
> > > harmles wrt functionality, but results in error messages such as
> > > 
> > > Mar 08 12:40:37 virtqemud[5639]: internal error: child reported 
> > > (status=125): unable to stat: /var/lib/libvirt/boot/vir>
> > > Mar 08 12:40:37 virtqemud[5639]: unable to stat: 
> > > /var/lib/libvirt/boot/virtinst-yvp19moo-linux: No such file or directo>
> > > Mar 08 12:40:37 virtqemud[5639]: Unable to run security manager 
> > > transaction
> > > 
> > > Avoid the messages by checking if the kernel and initrd still exist before
> > > including them in the restore label transaction.
> > > 
> > > Signed-off-by: Jim Fehlig 
> > > ---
> > >   src/security/security_dac.c | 4 ++--
> > >   src/security/security_selinux.c | 4 ++--
> > >   2 files changed, 4 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/src/security/security_dac.c b/src/security/security_dac.c
> > > index 4b8130630f..be606c6f33 100644
> > > --- a/src/security/security_dac.c
> > > +++ b/src/security/security_dac.c
> > > @@ -1993,11 +1993,11 @@ virSecurityDACRestoreAllLabel(virSecurityManager 
> > > *mgr,
> > >   rc = -1;
> > >   }
> > > -if (def->os.kernel &&
> > > +if (def->os.kernel && virFileExists(def->os.kernel) &&
> > >   virSecurityDACRestoreFileLabel(mgr, def->os.kernel) < 0)
> > >   rc = -1;
> > > -if (def->os.initrd &&
> > > +if (def->os.initrd && virFileExists(def->os.initrd) &&
> > >   virSecurityDACRestoreFileLabel(mgr, def->os.initrd) < 0)
> > >   rc = -1;
> > 
> > I wonder if this scenario is conceptually relevant to other
> > files though.
> > 
> > eg someone created a qcow2 overlay for the disk, to capture
> > writes, and then immediatley unlinked it as they wanted to
> > discard them. ie manual equivalent of QEMU's -snapshot
> > arg.
> > 
> > Should we instead plumb something in so that the 'stat()'
> > failure gets silently ignored when it is ENOENT, on a
> > "restore" code path
> 
> Something like the following works for the DAC driver
> 
> diff --git a/src/security/security_dac.c b/src/security/security_dac.c
> index 567be4bd23..28afa4846b 100644
> --- a/src/security/security_dac.c
> +++ b/src/security/security_dac.c
> @@ -667,7 +667,8 @@ virSecurityDACSetOwnershipInternal(const
> virSecurityDACData *priv,
> const virStorageSource *src,
> const char *path,
> uid_t uid,
> -   gid_t gid)
> +   gid_t gid,
> +   bool ignoreNoEnt)
>  {
>  int rc = 0;
> 
> @@ -689,6 +690,9 @@ virSecurityDACSetOwnershipInternal(const
> virSecurityDACData *priv,
>  return 0;
> 
>  if (stat(path, ) < 0) {
> +if (errno == ENOENT && ignoreNoEnt)
> +return 0;
> +
>  virReportSystemError(errno, _("unable to stat: %1$s"), path);
>  return -1;
>  }
> @@ -787,7 +791,7 @@ virSecurityDACSetOwnership(virSecurityManager *mgr,
>  VIR_INFO("Setting DAC user and group on '%s' to '%ld:%ld'",
>   NULLSTR(src ? src->path : path), (long)uid, (long)gid);
> 
> -if (virSecurityDACSetOwnershipInternal(priv, src, path, uid, gid) < 0)
> +if (virSecurityDACSetOwnershipInternal(priv, src, path, uid, gid, false) 
> < 0)
>  goto error;
> 
>  return 0;
> @@ -847,7 +851,7 @@ virSecurityDACRestoreFileLabelInternal(virSecurityManager 
> *mgr,
>  VIR_INFO("Restoring DAC user and group on '%s' to %ld:%ld",
>   NULLSTR(src ? src->path : path), (long)uid, (long)gid);
> 
> -return virSecurityDACSetOwnershipInternal(priv, src, path, uid, gid);
> +return virSecurityDACSetOwnershipInternal(priv, src, path, uid, gid, 
> true);
>  }
> 
> The selinux driver is not as simple. I suspect the call to
> virFileResolveLink() would fail if the file no longer exists, well before
> the call to stat()
> 
> https://gitlab.com/libvirt/libvirt/-/blob/master/src/security/security_selinux.c?ref_type=heads#L1494
> 
> Adding an 'ignoreNoEnt' parameter to virSecuritySELinuxRestoreFileLabel,
> plumbing it through to virFileResolveLink, and adjusting all call sites
> seems a bit overkill.
> 
> An FYI: while testing the above patch, I thought something simple like the
> below hack was a clever fix, but it causes several qemusecuritytest
> failures.

This 

Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated

2024-03-27 Thread Daniel P . Berrangé
On Tue, Mar 26, 2024 at 02:29:58PM +0100, Philippe Mathieu-Daudé wrote:
> Hi Igor,
> 
> On 26/3/24 14:08, Thomas Huth wrote:
> > 
> > s/iaspc/isapc/ in the subject
> > 
> > On 26/03/2024 13.51, Igor Mammedov wrote:
> > > ISAPC machine was introduced 25 years ago and it's a lot of time since
> > > such machine was around with real ISA only PC hardware practically
> > > defunct.
> > > Also it's slowly bit-rots (for example: I was able to boot RHEL6 on
> > > RHEL9 host
> > > in only TCG mode, while in KVM mode it hung in the middle of boot)
> 
> I'm quite opposed to this patch. QEMU models various very-old /
> defunct hardware. I'm pretty sure Bernhard and myself are OK to
> keep maintaining it, besides we are working in separating it from
> the i440fx+piix machine. Also, this machine is particularly
> interesting for my single-binary experiments.
> 
> Where I agree is we should stop reporting "KVM on ISA/PC machine"
> as supported.

isapc could arguably be restricted to just 32-bit CPU models, because
we should not need it to support any feature that didn't exist prior
to circa 1995. eg refuse to start with isapc, if 'lm' is present in
the CPU model for example.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated

2024-03-27 Thread Daniel P . Berrangé
On Wed, Mar 27, 2024 at 01:27:58PM +, Peter Maydell wrote:
> On Wed, 27 Mar 2024 at 13:23, Daniel P. Berrangé  wrote:
> >
> > On Wed, Mar 27, 2024 at 02:09:17PM +0100, Igor Mammedov wrote:
> > > On Wed, 27 Mar 2024 10:49:43 +
> > > Daniel P. Berrangé  wrote:
> > > It's question of whether we are willing to do unthinkable,
> > > i.e. to break QEMU <-> guest ABI for isapc case by removing
> > > corresponding fwcfg entries.
> >
> > There has never been any ABI stability requirement for 'isapc'
> > as it is not a versioned machine type.
> >
> > > With migration ignored it shouldn't be a problem.
> > > Question is: does anyone care about migration with isapc?
> > > If not, I'd gladly axe smbios legacy parts in 9.1
> >
> > Migration is irrelevant unless someone steps forward to
> > commit to long term versioning of the machine type.
> 
> But migration is also how we implement savevm/loadvm,
> which are useful even when the machine type is not versioned.
> So please don't put in migration blockers or similar that would
> break that.

Yep, that's valid use case within the scope of a single QEMU release.
We just can't guarantee it across versions. Often it'll probably work
but it is liable to break at times.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated

2024-03-27 Thread Peter Maydell
On Wed, 27 Mar 2024 at 13:23, Daniel P. Berrangé  wrote:
>
> On Wed, Mar 27, 2024 at 02:09:17PM +0100, Igor Mammedov wrote:
> > On Wed, 27 Mar 2024 10:49:43 +
> > Daniel P. Berrangé  wrote:
> > It's question of whether we are willing to do unthinkable,
> > i.e. to break QEMU <-> guest ABI for isapc case by removing
> > corresponding fwcfg entries.
>
> There has never been any ABI stability requirement for 'isapc'
> as it is not a versioned machine type.
>
> > With migration ignored it shouldn't be a problem.
> > Question is: does anyone care about migration with isapc?
> > If not, I'd gladly axe smbios legacy parts in 9.1
>
> Migration is irrelevant unless someone steps forward to
> commit to long term versioning of the machine type.

But migration is also how we implement savevm/loadvm,
which are useful even when the machine type is not versioned.
So please don't put in migration blockers or similar that would
break that.

thanks
-- PMM
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated

2024-03-27 Thread Philippe Mathieu-Daudé

On 27/3/24 14:09, Igor Mammedov wrote:

On Wed, 27 Mar 2024 10:49:43 +
Daniel P. Berrangé  wrote:


On Tue, Mar 26, 2024 at 05:16:32PM +0100, Igor Mammedov wrote:

On Tue, 26 Mar 2024 14:29:58 +0100
Philippe Mathieu-Daudé  wrote:
   

Hi Igor,

On 26/3/24 14:08, Thomas Huth wrote:


s/iaspc/isapc/ in the subject

On 26/03/2024 13.51, Igor Mammedov wrote:

ISAPC machine was introduced 25 years ago and it's a lot of time since
such machine was around with real ISA only PC hardware practically
defunct.
Also it's slowly bit-rots (for example: I was able to boot RHEL6 on
RHEL9 host
in only TCG mode, while in KVM mode it hung in the middle of boot)


I'm quite opposed to this patch. QEMU models various very-old /
defunct hardware. I'm pretty sure Bernhard and myself are OK to
keep maintaining it, besides we are working in separating it from
the i440fx+piix machine. Also, this machine is particularly
interesting for my single-binary experiments.


it would not be fair to ask you or Bernard to deal with every
case where ISAPC related code gets in a way, nor it's fair to
ask other contributors to ensure that their patches don't break
semi-working ISAPC or refactor code that relates to it.

[
for example I'd like to refactor smbios parts in the image
ACPI table builder, but the I'd have to do it for legacy
part as well without means to verify that. Sure it can be
done but at cost of extra time spent to rewrite something
that would never be used and to find test env to verify
touched code.
]


Is SMBIOS even relevant for isapc ? IIUC, the first SMBIOS spec
is from 1999, while PCI has been around since 1992.


Theoretically SMBIOS can still be used with isapc,
(that's how I've tested factoring out legacy part by running
RHEL6 in TCG mode)
Whether it's used in practice somewhere else is unknown.


IOW, we shouldn't even be exposing SMBIOS with the isapc
machine type. If we address that, then isapc has no impact
on your ability to refactor SMBIOS code.


It's question of whether we are willing to do unthinkable,
i.e. to break QEMU <-> guest ABI for isapc case by removing
corresponding fwcfg entries.

With migration ignored it shouldn't be a problem.
Question is: does anyone care about migration with isapc?
If not, I'd gladly axe smbios legacy parts in 9.1


But given how easy one can spawn old qemu environment to
run something on isapc, we are loosing a chance to cleanup
QEMU code base touching following

 m->option_rom_has_mr = true;
 m->rom_file_has_mr = false;
 pcmc->pci_enabled = false;
 pcmc->has_acpi_build = false;
 pcmc->smbios_defaults = false;
 pcmc->gigabyte_align = false;
 pcmc->smbios_legacy_mode = true;


My plan is to split the legacy part of fw_cfg_build_smbios() out
of it as fw_cfg_build_smbios_legacy().


 pcmc->has_reserved_memory = false;

they are all marginal but in shared code, and removing them
makes code a bit more easier to follow (especially when it
comes to memory layout).


With regards,
Daniel



___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated

2024-03-27 Thread Daniel P . Berrangé
On Wed, Mar 27, 2024 at 02:09:17PM +0100, Igor Mammedov wrote:
> On Wed, 27 Mar 2024 10:49:43 +
> Daniel P. Berrangé  wrote:
> 
> > On Tue, Mar 26, 2024 at 05:16:32PM +0100, Igor Mammedov wrote:
> > > On Tue, 26 Mar 2024 14:29:58 +0100
> > > Philippe Mathieu-Daudé  wrote:
> > >   
> > > > Hi Igor,
> > > > 
> > > > On 26/3/24 14:08, Thomas Huth wrote:  
> > > > > 
> > > > > s/iaspc/isapc/ in the subject
> > > > > 
> > > > > On 26/03/2024 13.51, Igor Mammedov wrote:
> > > > >> ISAPC machine was introduced 25 years ago and it's a lot of time 
> > > > >> since
> > > > >> such machine was around with real ISA only PC hardware practically 
> > > > >> defunct.
> > > > >> Also it's slowly bit-rots (for example: I was able to boot RHEL6 on 
> > > > >> RHEL9 host
> > > > >> in only TCG mode, while in KVM mode it hung in the middle of boot)   
> > > > >>  
> > > > 
> > > > I'm quite opposed to this patch. QEMU models various very-old /
> > > > defunct hardware. I'm pretty sure Bernhard and myself are OK to
> > > > keep maintaining it, besides we are working in separating it from
> > > > the i440fx+piix machine. Also, this machine is particularly
> > > > interesting for my single-binary experiments.  
> > > 
> > > it would not be fair to ask you or Bernard to deal with every
> > > case where ISAPC related code gets in a way, nor it's fair to
> > > ask other contributors to ensure that their patches don't break
> > > semi-working ISAPC or refactor code that relates to it. 
> > > 
> > > [
> > > for example I'd like to refactor smbios parts in the image
> > > ACPI table builder, but the I'd have to do it for legacy
> > > part as well without means to verify that. Sure it can be
> > > done but at cost of extra time spent to rewrite something
> > > that would never be used and to find test env to verify
> > > touched code.
> > > ]  
> > 
> > Is SMBIOS even relevant for isapc ? IIUC, the first SMBIOS spec
> > is from 1999, while PCI has been around since 1992.
> 
> Theoretically SMBIOS can still be used with isapc,
> (that's how I've tested factoring out legacy part by running
> RHEL6 in TCG mode) 
> Whether it's used in practice somewhere else is unknown. 
> 
> > IOW, we shouldn't even be exposing SMBIOS with the isapc
> > machine type. If we address that, then isapc has no impact
> > on your ability to refactor SMBIOS code.
> 
> It's question of whether we are willing to do unthinkable,
> i.e. to break QEMU <-> guest ABI for isapc case by removing
> corresponding fwcfg entries.

There has never been any ABI stability requirement for 'isapc'
as it is not a versioned machine type.

> With migration ignored it shouldn't be a problem.
> Question is: does anyone care about migration with isapc?
> If not, I'd gladly axe smbios legacy parts in 9.1

Migration is irrelevant unless someone steps forward to
commit to long term versioning of the machine type.

> But given how easy one can spawn old qemu environment to

There are ways to get access to an old QEMU, but I would
not call them easy when compared to using the QEMU that
is shipped as standard by your distro.

For a while a tried to maintain an archive of old QEMU
versions built for modern distros and it was a surprisingly
painful exercise. We tend to forget just how often QEMU's
build gets broken by new compilers, or new glibc system
header changes, or other 3rd party packages. 

Telling users to find an old QEMU is not an attractive
proposition, except as a last resort.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH-for-9.1] target/nios2: Remove machines and system emulation

2024-03-27 Thread Thomas Huth

On 27/03/2024 13.45, Philippe Mathieu-Daudé wrote:

On 27/3/24 13:35, Philippe Mathieu-Daudé wrote:

Remove the Nios II machines and the system emulation code
(deprecated since v8.2 in commit 9997771bc1 "target/nios2:
Deprecate the Nios II architecture").


Please remind me, why didn't we deprecate the linux-user emulation, too?


diff --git a/hw/nios2/Kconfig b/hw/nios2/Kconfig
deleted file mode 100644
index 4748ae27b6..00
--- a/hw/nios2/Kconfig
+++ /dev/null
@@ -1,13 +0,0 @@
-config NIOS2_10M50
-    bool
-    select NIOS2
-    select SERIAL
-    select ALTERA_TIMER


I forgot to mention I deliberately chose to keep the Altera
timer model in the tree, since it looks like a re-usable
IP component.


But if it is not used anymore by any machine, this will happily bitrot, 
won't it? I think I'd rather remove it, too ... maybe in a separate patch, 
so that in case somebody later needs it again, it can be restored by simply 
reverting the patch again.


 Thomas
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated

2024-03-27 Thread Thomas Huth

On 27/03/2024 14.09, Igor Mammedov wrote:

On Wed, 27 Mar 2024 10:49:43 +
Daniel P. Berrangé  wrote:


On Tue, Mar 26, 2024 at 05:16:32PM +0100, Igor Mammedov wrote:

On Tue, 26 Mar 2024 14:29:58 +0100
Philippe Mathieu-Daudé  wrote:
   

Hi Igor,

On 26/3/24 14:08, Thomas Huth wrote:


s/iaspc/isapc/ in the subject

On 26/03/2024 13.51, Igor Mammedov wrote:

ISAPC machine was introduced 25 years ago and it's a lot of time since
such machine was around with real ISA only PC hardware practically
defunct.
Also it's slowly bit-rots (for example: I was able to boot RHEL6 on
RHEL9 host
in only TCG mode, while in KVM mode it hung in the middle of boot)


I'm quite opposed to this patch. QEMU models various very-old /
defunct hardware. I'm pretty sure Bernhard and myself are OK to
keep maintaining it, besides we are working in separating it from
the i440fx+piix machine. Also, this machine is particularly
interesting for my single-binary experiments.


it would not be fair to ask you or Bernard to deal with every
case where ISAPC related code gets in a way, nor it's fair to
ask other contributors to ensure that their patches don't break
semi-working ISAPC or refactor code that relates to it.

[
for example I'd like to refactor smbios parts in the image
ACPI table builder, but the I'd have to do it for legacy
part as well without means to verify that. Sure it can be
done but at cost of extra time spent to rewrite something
that would never be used and to find test env to verify
touched code.
]


Is SMBIOS even relevant for isapc ? IIUC, the first SMBIOS spec
is from 1999, while PCI has been around since 1992.


Theoretically SMBIOS can still be used with isapc,
(that's how I've tested factoring out legacy part by running
RHEL6 in TCG mode)
Whether it's used in practice somewhere else is unknown.


IOW, we shouldn't even be exposing SMBIOS with the isapc
machine type. If we address that, then isapc has no impact
on your ability to refactor SMBIOS code.


It's question of whether we are willing to do unthinkable,
i.e. to break QEMU <-> guest ABI for isapc case by removing
corresponding fwcfg entries.

With migration ignored it shouldn't be a problem.
Question is: does anyone care about migration with isapc?


isapc is not versioned, so it is not really usable with migration at all, I 
think. We should maybe even add a migration blocker for that machine to 
avoid that people try to migrate it.


I just gave it also a quick try, and it currently seems to be broken anyway 
(aborts with "memory_region_set_alias_offset: Assertion `mr->alias' failed").


 Thomas
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated

2024-03-27 Thread Igor Mammedov
On Wed, 27 Mar 2024 10:49:43 +
Daniel P. Berrangé  wrote:

> On Tue, Mar 26, 2024 at 05:16:32PM +0100, Igor Mammedov wrote:
> > On Tue, 26 Mar 2024 14:29:58 +0100
> > Philippe Mathieu-Daudé  wrote:
> >   
> > > Hi Igor,
> > > 
> > > On 26/3/24 14:08, Thomas Huth wrote:  
> > > > 
> > > > s/iaspc/isapc/ in the subject
> > > > 
> > > > On 26/03/2024 13.51, Igor Mammedov wrote:
> > > >> ISAPC machine was introduced 25 years ago and it's a lot of time since
> > > >> such machine was around with real ISA only PC hardware practically 
> > > >> defunct.
> > > >> Also it's slowly bit-rots (for example: I was able to boot RHEL6 on 
> > > >> RHEL9 host
> > > >> in only TCG mode, while in KVM mode it hung in the middle of boot)
> > > 
> > > I'm quite opposed to this patch. QEMU models various very-old /
> > > defunct hardware. I'm pretty sure Bernhard and myself are OK to
> > > keep maintaining it, besides we are working in separating it from
> > > the i440fx+piix machine. Also, this machine is particularly
> > > interesting for my single-binary experiments.  
> > 
> > it would not be fair to ask you or Bernard to deal with every
> > case where ISAPC related code gets in a way, nor it's fair to
> > ask other contributors to ensure that their patches don't break
> > semi-working ISAPC or refactor code that relates to it. 
> > 
> > [
> > for example I'd like to refactor smbios parts in the image
> > ACPI table builder, but the I'd have to do it for legacy
> > part as well without means to verify that. Sure it can be
> > done but at cost of extra time spent to rewrite something
> > that would never be used and to find test env to verify
> > touched code.
> > ]  
> 
> Is SMBIOS even relevant for isapc ? IIUC, the first SMBIOS spec
> is from 1999, while PCI has been around since 1992.

Theoretically SMBIOS can still be used with isapc,
(that's how I've tested factoring out legacy part by running
RHEL6 in TCG mode) 
Whether it's used in practice somewhere else is unknown. 

> IOW, we shouldn't even be exposing SMBIOS with the isapc
> machine type. If we address that, then isapc has no impact
> on your ability to refactor SMBIOS code.

It's question of whether we are willing to do unthinkable,
i.e. to break QEMU <-> guest ABI for isapc case by removing
corresponding fwcfg entries.

With migration ignored it shouldn't be a problem.
Question is: does anyone care about migration with isapc?
If not, I'd gladly axe smbios legacy parts in 9.1


But given how easy one can spawn old qemu environment to
run something on isapc, we are loosing a chance to cleanup
QEMU code base touching following 

m->option_rom_has_mr = true;
 
m->rom_file_has_mr = false; 
 
pcmc->pci_enabled = false;  
 
pcmc->has_acpi_build = false;   
 
pcmc->smbios_defaults = false;  
 
pcmc->gigabyte_align = false;   
 
pcmc->smbios_legacy_mode = true;
 
pcmc->has_reserved_memory = false;

they are all marginal but in shared code, and removing them
makes code a bit more easier to follow (especially when it
comes to memory layout).

> With regards,
> Daniel
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH-for-9.1 v2 02/21] hw/usb/hcd-xhci: Remove XHCI_FLAG_FORCE_PCIE_ENDCAP flag

2024-03-27 Thread Zhao Liu
On Wed, Mar 27, 2024 at 10:51:04AM +0100, Philippe Mathieu-Daudé wrote:
> Date: Wed, 27 Mar 2024 10:51:04 +0100
> From: Philippe Mathieu-Daudé 
> Subject: [PATCH-for-9.1 v2 02/21] hw/usb/hcd-xhci: Remove
>  XHCI_FLAG_FORCE_PCIE_ENDCAP flag
> X-Mailer: git-send-email 2.41.0
> 
> XHCI_FLAG_FORCE_PCIE_ENDCAP was only used by the
> pc-i440fx-2.0 machine, which got removed. Remove it
> and simplify usb_xhci_pci_realize().
> 
> Reviewed-by: Thomas Huth 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/usb/hcd-xhci.h | 1 -
>  hw/usb/hcd-xhci-nec.c | 2 --
>  hw/usb/hcd-xhci-pci.c | 3 +--
>  3 files changed, 1 insertion(+), 5 deletions(-)

Reviewed-by: Zhao Liu 
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH-for-9.1 v2 01/21] hw/i386/pc: Remove deprecated pc-i440fx-2.0 machine

2024-03-27 Thread Zhao Liu
On Wed, Mar 27, 2024 at 10:51:03AM +0100, Philippe Mathieu-Daudé wrote:
> Date: Wed, 27 Mar 2024 10:51:03 +0100
> From: Philippe Mathieu-Daudé 
> Subject: [PATCH-for-9.1 v2 01/21] hw/i386/pc: Remove deprecated
>  pc-i440fx-2.0 machine
> X-Mailer: git-send-email 2.41.0
> 
> The pc-i440fx-2.0 machine was deprecated for the 8.2
> release (see commit c7437f0ddb "docs/about: Mark the
> old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
> time to remove it.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> Reviewed-by: Thomas Huth 
> Message-Id: <20240305134221.30924-2-phi...@linaro.org>
> ---
>  docs/about/deprecated.rst   |  2 +-
>  docs/about/removed-features.rst |  2 +-
>  include/hw/i386/pc.h|  3 ---
>  hw/i386/pc.c| 15 -
>  hw/i386/pc_piix.c   | 37 -
>  5 files changed, 2 insertions(+), 57 deletions(-)

Reviewed-by: Zhao Liu 
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH v2] Extend libvirt-guests to shutdown only persistent VMs

2024-03-27 Thread Benjamin Taubmann
At the moment, there is no configuration option for the libvirt-guests
service that allows users to define that only persistent virtual machines
should be shutdown on host shutdown.

Currently, the service config allows to choose between two ON_SHUTDOWN
actions that are executed on running virtual machines when the host goes
down: shutdown, suspend.
The ON_SHUTDOWN action should be orthogonal to the type of the virtual
machine. However, the existing implementation, does not suspend
transient virtual machines.
This is the matrix of actions that is executed on virtual machines based
on the configured ON_SHUTDOWN action and the type of a virtual machine.

 | persistent | transient
shutdown | shutdown   | shutdown (what we want to change)
suspend  | suspend| nothing

Add config option PERSISTENT_ONLY to libvirt-guests config that allows
users to define if the ON_SHUTDOWN action should be applied only on
persistent virtual machines. PERSISTENT_ONLY can be set to true, false,
default. The default option will implement the already existing logic.

Case 1: PERSISTENT_ONLY=default
 | persistent | transient
shutdown | shutdown   | shutdown
suspend  | suspend| nothing

Case 2: PERSISTENT_ONLY=true
 | persistent | transient
shutdown | shutdown   | nothing
suspend  | suspend| nothing

Case 3: PERSISTENT_ONLY=false
 | persistent | transient
shutdown | shutdown   | shutdown
suspend  | suspend| suspend

Signed-off-by: Benjamin Taubmann 
Reviewed-by: Martin Kletzander 
---
v2: Update libvirt-guests' man page and git commit message
---
 docs/manpages/libvirt-guests.rst | 22 +++
 tools/libvirt-guests.sh.in   | 37 ++--
 2 files changed, 52 insertions(+), 7 deletions(-)

diff --git a/docs/manpages/libvirt-guests.rst b/docs/manpages/libvirt-guests.rst
index f27eaad6e4..42dae283e3 100644
--- a/docs/manpages/libvirt-guests.rst
+++ b/docs/manpages/libvirt-guests.rst
@@ -113,6 +113,28 @@ The following variables are supported:
   this requires guest agent with support for time synchronization
   running in the guest. By default, this functionality is turned off.
 
+- PERSISTENT_ONLY=default
+
+  Defines what type of guest virtual machine ON_SHUTDOWN action is applied to
+
+  * default
+
+This implements the already existing default behavior.
+If ON_SHUTDOWN action is shutdown, transient and persistent guest virtual
+machines are asked to shutdown.
+If ON_SHUTDOWN action is suspend, only persistent guest virtual machines
+are asked to suspend.
+
+  * true
+
+ON_SHUTDOWN action is executed only on persistent guest virtual machines.
+Transient guest virtual machines are not affected.
+
+  * false
+
+ON_SHUTDOWN action is executed on persistent and transient guest virtual
+machines.
+
 
 BUGS
 
diff --git a/tools/libvirt-guests.sh.in b/tools/libvirt-guests.sh.in
index 344b54390a..c3c5954e17 100644
--- a/tools/libvirt-guests.sh.in
+++ b/tools/libvirt-guests.sh.in
@@ -38,6 +38,7 @@ PARALLEL_SHUTDOWN=0
 START_DELAY=0
 BYPASS_CACHE=0
 SYNC_TIME=0
+PERSISTENT_ONLY="default"
 
 test -f "$initconfdir"/libvirt-guests &&
 . "$initconfdir"/libvirt-guests
@@ -438,14 +439,16 @@ shutdown_guests_parallel()
 # stop
 # Shutdown or save guests on the configured uris
 stop() {
-local suspending="true"
 local uri=
+local action="suspend"
+local persistent_only="default"
+
 
 # last stop was not followed by start
 [ -f "$LISTFILE" ] && return 0
 
 if [ "x$ON_SHUTDOWN" = xshutdown ]; then
-suspending="false"
+action="shutdown"
 if [ $SHUTDOWN_TIMEOUT -lt 0 ]; then
 gettext "SHUTDOWN_TIMEOUT must be equal or greater than 0"
 echo
@@ -454,6 +457,22 @@ stop() {
 fi
 fi
 
+case "x$PERSISTENT_ONLY" in
+xtrue)
+persistent_only="true"
+;;
+xfalse)
+persistent_only="false"
+;;
+*)
+if [ "x$action" = xshutdown ]; then
+persistent_only="false"
+elif [ "x$action" = xsuspend ]; then
+persistent_only="true"
+fi
+;;
+esac
+
 : >"$LISTFILE"
 set -f
 for uri in $URIS; do
@@ -478,7 +497,7 @@ stop() {
 echo
 fi
 
-if "$suspending"; then
+if "$persistent_only"; then
 local transient="$(list_guests "$uri" "--transient")"
 if [ $? -eq 0 ]; then
 local empty="true"
@@ -486,7 +505,11 @@ stop() {
 
 for uuid in $transient; do
 if "$empty"; then
-eval_gettext "Not suspending transient guests on URI: 
\$uri: "
+if [ "x$action" = xsuspend ]; then
+eval_gettext "Not suspending transient guests on 
URI: \$uri: "
+else
+eval_gettext "Not shutting down 

Re: [PATCH-for-9.0 0/2] target/monitor: Deprecate 'info tlb/mem' in favor of 'info mmu'

2024-03-27 Thread Dr. David Alan Gilbert
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On Wed, 20 Mar 2024 at 17:06, Philippe Mathieu-Daudé  
> wrote:
> >
> > +Alex/Daniel
> >
> > On 20/3/24 17:53, Peter Maydell wrote:
> > > On Wed, 20 Mar 2024 at 16:40, Philippe Mathieu-Daudé  
> > > wrote:
> > >>
> > >> 'info tlb' and 'info mem' commands don't scale in heterogeneous
> > >> emulation. They will be reworked after the next release, hidden
> > >> behind the 'info mmu' command. It is not too late to deprecate
> > >> commands, so add the 'info mmu' command as wrapper to the other
> > >> ones, but already deprecate them.
> > >>
> > >> Philippe Mathieu-Daudé (2):
> > >>target/monitor: Introduce 'info mmu' command
> > >>target/monitor: Deprecate 'info tlb' and 'info mem' commands
> > >
> > > This seems to replace "info tlb" and "info mem" with "info mmu -t"
> > > and "info mmu -m", but it doesn't really say anything about:
> > >   * what the difference is between these two things
> >
> > I really don't know; I'm only trying to keep the monitor interface
> > identical.
> 
> You don't, though: you change it from "info tlb" to "info mmu -t" etc.
> 
> > >   * which targets implement which and why
> >
> > This one is easy to answer:
> >
> > #if defined(TARGET_I386) || defined(TARGET_SH4) || defined(TARGET_SPARC)
> > || \
> >  defined(TARGET_PPC) || defined(TARGET_XTENSA) || defined(TARGET_M68K)
> >  {
> >  .name   = "tlb",
> >
> > #if defined(TARGET_I386) || defined(TARGET_RISCV)
> >  {
> >  .name   = "mem",
> >
> > >   * what the plan is for the future
> >
> > My problem is with linking a single QEMU binary, as these two symbols
> > (hmp_info_mem and hmp_info_tlb) clash.
> 
> Yes, but they both (implicitly) operate on the current HMP CPU,
> so the problem with linking into a single binary is that they're
> not indirected through a method on the CPU object, not the syntax
> used in the monitor to invoke them, presumably.
> 
> > I'm indeed only postponing the problem, without looking at what
> > this code does. I did it adding hmp_info_mmu_tlb/mem hooks in
> > TCGCPUOps ("hw/core/tcg-cpu-ops.h"), so the command can be
> > dispatched per target vcpu as target-agnostic code in
> > monitor/hmp-cmds.c:
> >
> > +#include "hw/core/tcg-cpu-ops.h"
> > +
> > +static void hmp_info_mmu_tlb(Monitor *mon, CPUState *cpu)
> > +{
> > +const TCGCPUOps *tcg_ops = cpu->cc->tcg_ops;
> > +
> > +if (tcg_ops->hmp_info_mmu_tlb) {
> > +tcg_ops->hmp_info_mmu_tlb(mon, cpu_env(cpu));
> > +} else {
> > +monitor_puts(mon, "No per-CPU information available on this
> > target\n");
> > +}
> > +}
> 
> These aren't TCG specific though, so why TCGCPUOps ?
> 
> > > I am definitely not a fan of either of these commands, because
> > > (as we currently implement them) they effectively require each
> > > target architecture to implement a second copy of the page table
> > > walking code. But before we can deprecate them we need to be
> > > pretty sure that "info mmu" is what we want to replace them with.
> >
> > An alternative is to just deprecate them, without adding "info mmu" :)
> >
> > It is OK to un-deprecate stuff if we realize its usefulness.
> 
> The commands are there because some users find them useful.
> I just dislike them because I think they're a bit niche and
> annoying to implement and not consistent across target
> architectures and not very well documented...
> 
> By the way, we have no obligation to follow the deprecate-and-drop
> process for HMP commands; unlike QMP, we give ourselves the
> license to vary it when we feel like it, because the users are
> humans, not programs or scripts.

Right, so no rush to get the deprecation in; change it when you agree
what you'd like a replacement to look like.

Dave

> -- PMM
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH] virsysinfo: Try reading DMI table

2024-03-27 Thread Kristina Hanicova
On Tue, Mar 26, 2024 at 8:45 PM  wrote:

> From: Brett Holman 
>
> Add DMI support for risc-v and mips. Attempt to read dmidecode and
> fall back to old behavior if that fails.
>
> The SMBIOS specification[1] officially supports both RISC-V and LoongArch.
> Some mips-based Loongson-3 processors also have SMBIOS.
>
> [1]
> https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.7.0.pdf
>
> Signed-off-by: Brett Holman 
> ---
>  src/util/virsysinfo.c | 2 ++
>  1 file changed, 2 insertions(+)
>

Reviewed-by: Kristina Hanicova 
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH-for-9.1] target/nios2: Remove machines and system emulation

2024-03-27 Thread Philippe Mathieu-Daudé

On 27/3/24 13:35, Philippe Mathieu-Daudé wrote:

Remove the Nios II machines and the system emulation code
(deprecated since v8.2 in commit 9997771bc1 "target/nios2:
Deprecate the Nios II architecture").

Cc: Marek Vasut 
Signed-off-by: Philippe Mathieu-Daudé 
---
  MAINTAINERS   |   4 -
  docs/about/deprecated.rst |   5 -
  docs/about/emulation.rst  |   3 -
  docs/about/removed-features.rst   |   5 +
  docs/system/replay.rst|   2 +-
  configs/devices/nios2-softmmu/default.mak |   6 -
  configs/targets/nios2-softmmu.mak |   2 -
  qapi/machine.json |   2 +-
  hw/nios2/boot.h   |  10 -
  include/hw/intc/nios2_vic.h   |  66 
  include/sysemu/arch_init.h|   1 -
  target/nios2/cpu-param.h  |   6 +-
  target/nios2/cpu.h|  42 ---
  target/nios2/helper.h |   9 -
  target/nios2/mmu.h|  52 ---
  hw/intc/nios2_vic.c   | 313 --
  hw/nios2/10m50_devboard.c | 181 ---
  hw/nios2/boot.c   | 234 --
  hw/nios2/generic_nommu.c  | 101 --
  target/nios2/cpu.c| 160 +-
  target/nios2/helper.c | 371 --
  target/nios2/mmu.c| 216 -
  target/nios2/monitor.c|  35 --
  target/nios2/nios2-semi.c | 230 --
  target/nios2/op_helper.c  |  45 ---
  target/nios2/translate.c  | 254 +--
  tests/qtest/machine-none-test.c   |   1 -
  .gitlab-ci.d/buildtest.yml|   4 +-
  .gitlab-ci.d/crossbuilds.yml  |   2 +-
  hw/Kconfig|   1 -
  hw/intc/Kconfig   |   3 -
  hw/intc/meson.build   |   1 -
  hw/meson.build|   1 -
  hw/nios2/Kconfig  |  13 -
  hw/nios2/meson.build  |   6 -
  qemu-options.hx   |   8 +-
  scripts/coverity-scan/COMPONENTS.md   |   2 +-
  target/nios2/meson.build  |   9 -
  tests/avocado/boot_linux_console.py   |   8 -
  tests/avocado/replay_kernel.py|  11 -
  tests/tcg/nios2/Makefile.softmmu-target   |  32 --
  tests/tcg/nios2/test-shadow-1.S   |  40 ---
  42 files changed, 24 insertions(+), 2473 deletions(-)
  delete mode 100644 configs/devices/nios2-softmmu/default.mak
  delete mode 100644 configs/targets/nios2-softmmu.mak
  delete mode 100644 hw/nios2/boot.h
  delete mode 100644 include/hw/intc/nios2_vic.h
  delete mode 100644 target/nios2/mmu.h
  delete mode 100644 hw/intc/nios2_vic.c
  delete mode 100644 hw/nios2/10m50_devboard.c
  delete mode 100644 hw/nios2/boot.c
  delete mode 100644 hw/nios2/generic_nommu.c
  delete mode 100644 target/nios2/helper.c
  delete mode 100644 target/nios2/mmu.c
  delete mode 100644 target/nios2/monitor.c
  delete mode 100644 target/nios2/nios2-semi.c
  delete mode 100644 hw/nios2/Kconfig
  delete mode 100644 hw/nios2/meson.build
  delete mode 100644 tests/tcg/nios2/Makefile.softmmu-target
  delete mode 100644 tests/tcg/nios2/test-shadow-1.S




diff --git a/hw/nios2/Kconfig b/hw/nios2/Kconfig
deleted file mode 100644
index 4748ae27b6..00
--- a/hw/nios2/Kconfig
+++ /dev/null
@@ -1,13 +0,0 @@
-config NIOS2_10M50
-bool
-select NIOS2
-select SERIAL
-select ALTERA_TIMER


I forgot to mention I deliberately chose to keep the Altera
timer model in the tree, since it looks like a re-usable
IP component.
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [libvirt PATCH 2/2] qemu_snapshot: correctly update metadata when deleting external snapshot with multiple branches

2024-03-27 Thread Peter Krempa
On Mon, Feb 26, 2024 at 14:40:50 +0100, Pavel Hrdina wrote:
> XML metadata for snapshot contains only single list of disk overlays
> from the moment when the snapshot was taken. When user creates multiple
> branches of snapshots the parent snapshot will still list only the
> original disk overlays. This may cause an issue in a specific scenario:
> 
>  s1
>   |
>   +- s2
>   +- s3 (active)
> 
> For this snapshot topology when we delete s2 metadata for s1 are not
> updated. Now when we delete s1 the code operated with incorrect
> overlays from s1 metadata in order to update s3 metadata resulting in no
> changes to s3 metadata.
> 
> Now when user tries to delete s3 it fails with following error:
> 
> error: Failed to delete snapshot s3
> error: operation failed: snapshot VM disk source and parent disk source 
> are not the same
> 
> For the actual deletion there is a code to figure out the correct disk
> source but it was not used to update metadata as well. Due to reasons
> how block commit in libvirt works we need to create a copy of that disk
> source in order to have it available when updating metadata as the
> original source will be freed at that point.
> 
> Resolves: https://issues.redhat.com/browse/RHEL-26276
> Signed-off-by: Pavel Hrdina 
> ---
>  src/qemu/qemu_snapshot.c | 34 +-
>  1 file changed, 21 insertions(+), 13 deletions(-)

Reviewed-by: Peter Krempa 
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [libvirt PATCH 1/2] qemu_snapshot: call qemuSnapshotDeleteUpdateDisks only for external snapshots

2024-03-27 Thread Peter Krempa
On Mon, Feb 26, 2024 at 14:40:49 +0100, Pavel Hrdina wrote:
> Calling this function when deleting internal snapshot isn't required
> because with internal snapshots all changes are done within the file
> itself so there is no file deletion and no need to update snapshot
> metadata.
> 
> Signed-off-by: Pavel Hrdina 
> ---
>  src/qemu/qemu_snapshot.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)

Reviewed-by: Peter Krempa 
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH-for-9.1 v2 13/21] hw/mem/pc-dimm: Remove legacy_align argument from pc_dimm_pre_plug()

2024-03-27 Thread David Hildenbrand

On 27.03.24 10:51, Philippe Mathieu-Daudé wrote:

'legacy_align' is always NULL, remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-11-phi...@linaro.org>
---


I was really confused for a second until I saw that this series is 
dependent on another one.


Please make sure to CC people you CC on patches to also CC on the cover 
letter.


Reviewed-by: David Hildenbrand 

--
Cheers,

David / dhildenb
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH-for-9.1 v2 14/21] hw/mem/memory-device: Remove legacy_align from memory_device_pre_plug()

2024-03-27 Thread David Hildenbrand

  void memory_device_pre_plug(MemoryDeviceState *md, MachineState *ms,
-const uint64_t *legacy_align, Error **errp)
+Error **errp)
  {
  const MemoryDeviceClass *mdc = MEMORY_DEVICE_GET_CLASS(md);
  Error *local_err = NULL;
@@ -388,14 +388,10 @@ void memory_device_pre_plug(MemoryDeviceState *md, 
MachineState *ms,
  return;
  }
  
-if (legacy_align) {

-align = *legacy_align;
-} else {
-if (mdc->get_min_alignment) {
-align = mdc->get_min_alignment(md);
-}
-align = MAX(align, memory_region_get_alignment(mr));
+if (mdc->get_min_alignment) {
+align = mdc->get_min_alignment(md);
  }
+align = MAX(align, memory_region_get_alignment(mr));
  addr = mdc->get_addr(md);
  addr = memory_device_get_free_addr(ms, !addr ? NULL : , align,
 memory_region_size(mr), _err);


Very nice!

Reviewed-by: David Hildenbrand 

--
Cheers,

David / dhildenb
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated

2024-03-27 Thread Daniel P . Berrangé
On Tue, Mar 26, 2024 at 05:16:32PM +0100, Igor Mammedov wrote:
> On Tue, 26 Mar 2024 14:29:58 +0100
> Philippe Mathieu-Daudé  wrote:
> 
> > Hi Igor,
> > 
> > On 26/3/24 14:08, Thomas Huth wrote:
> > > 
> > > s/iaspc/isapc/ in the subject
> > > 
> > > On 26/03/2024 13.51, Igor Mammedov wrote:  
> > >> ISAPC machine was introduced 25 years ago and it's a lot of time since
> > >> such machine was around with real ISA only PC hardware practically 
> > >> defunct.
> > >> Also it's slowly bit-rots (for example: I was able to boot RHEL6 on 
> > >> RHEL9 host
> > >> in only TCG mode, while in KVM mode it hung in the middle of boot)  
> > 
> > I'm quite opposed to this patch. QEMU models various very-old /
> > defunct hardware. I'm pretty sure Bernhard and myself are OK to
> > keep maintaining it, besides we are working in separating it from
> > the i440fx+piix machine. Also, this machine is particularly
> > interesting for my single-binary experiments.
> 
> it would not be fair to ask you or Bernard to deal with every
> case where ISAPC related code gets in a way, nor it's fair to
> ask other contributors to ensure that their patches don't break
> semi-working ISAPC or refactor code that relates to it. 
> 
> [
> for example I'd like to refactor smbios parts in the image
> ACPI table builder, but the I'd have to do it for legacy
> part as well without means to verify that. Sure it can be
> done but at cost of extra time spent to rewrite something
> that would never be used and to find test env to verify
> touched code.
> ]

Is SMBIOS even relevant for isapc ? IIUC, the first SMBIOS spec
is from 1999, while PCI has been around since 1992.

IOW, we shouldn't even be exposing SMBIOS with the isapc
machine type. If we address that, then isapc has no impact
on your ability to refactor SMBIOS code.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 21/21] hw/i386/pc: Replace PCMachineClass::acpi_data_size by PC_ACPI_DATA_SIZE

2024-03-27 Thread Philippe Mathieu-Daudé
PCMachineClass::acpi_data_size was only used by the pc-i440fx-2.0
machine, which got removed. Since it is constant, replace the class
field by a definition.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-19-phi...@linaro.org>
---
 include/hw/i386/pc.h |  4 
 hw/i386/pc.c | 19 ---
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 96ccb4583f..0ad971782c 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -74,9 +74,6 @@ typedef struct PCMachineState {
  *
  * Compat fields:
  *
- * @acpi_data_size: Size of the chunk of memory at the top of RAM
- *  for the BIOS ACPI tables and other BIOS
- *  datastructures.
  * @gigabyte_align: Make sure that guest addresses aligned at
  *  1Gbyte boundaries get mapped to host
  *  addresses aligned at 1Gbyte boundaries. This
@@ -100,7 +97,6 @@ struct PCMachineClass {
 
 /* ACPI compat: */
 bool has_acpi_build;
-unsigned acpi_data_size;
 int pci_root_uid;
 
 /* SMBIOS compat: */
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 27e04c52f6..f01a30d3d9 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -256,6 +256,16 @@ GlobalProperty pc_compat_2_4[] = {
 };
 const size_t pc_compat_2_4_len = G_N_ELEMENTS(pc_compat_2_4);
 
+/*
+ * @PC_ACPI_DATA_SIZE:
+ * Size of the chunk of memory at the top of RAM for the BIOS ACPI tables
+ * and other BIOS datastructures.
+ *
+ * BIOS ACPI tables: 128K. Other BIOS datastructures: less than 4K
+ * reported to be used at the moment, 32K should be enough for a while.
+ */
+#define PC_ACPI_DATA_SIZE (0x2 + 0x8000)
+
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
 {
 GSIState *s;
@@ -634,8 +644,7 @@ void xen_load_linux(PCMachineState *pcms)
 fw_cfg_add_i16(fw_cfg, FW_CFG_NB_CPUS, x86ms->boot_cpus);
 rom_set_fw(fw_cfg);
 
-x86_load_linux(x86ms, fw_cfg, pcmc->acpi_data_size,
-   pcmc->pvh_enabled);
+x86_load_linux(x86ms, fw_cfg, PC_ACPI_DATA_SIZE, pcmc->pvh_enabled);
 for (i = 0; i < nb_option_roms; i++) {
 assert(!strcmp(option_rom[i].name, "linuxboot.bin") ||
!strcmp(option_rom[i].name, "linuxboot_dma.bin") ||
@@ -969,8 +978,7 @@ void pc_memory_init(PCMachineState *pcms,
 }
 
 if (linux_boot) {
-x86_load_linux(x86ms, fw_cfg, pcmc->acpi_data_size,
-   pcmc->pvh_enabled);
+x86_load_linux(x86ms, fw_cfg, PC_ACPI_DATA_SIZE, pcmc->pvh_enabled);
 }
 
 for (i = 0; i < nb_option_roms; i++) {
@@ -1722,9 +1730,6 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 pcmc->gigabyte_align = true;
 pcmc->has_reserved_memory = true;
 pcmc->enforce_amd_1tb_hole = true;
-/* BIOS ACPI tables: 128K. Other BIOS datastructures: less than 4K reported
- * to be used at the moment, 32K should be enough for a while.  */
-pcmc->acpi_data_size = 0x2 + 0x8000;
 pcmc->pvh_enabled = true;
 pcmc->kvmclock_create_always = true;
 x86mc->apic_xrupt_override = true;
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 20/21] target/i386: Remove X86CPU::kvm_no_smi_migration field

2024-03-27 Thread Philippe Mathieu-Daudé
X86CPU::kvm_no_smi_migration was only used by the
pc-i440fx-2.3 machine, which got removed. Remove it
and simplify kvm_put_vcpu_events().

Signed-off-by: Philippe Mathieu-Daudé 
---
 target/i386/cpu.h | 3 ---
 target/i386/cpu.c | 2 --
 target/i386/kvm/kvm.c | 7 +--
 3 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 6b05738079..5b016d6667 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -2018,9 +2018,6 @@ struct ArchCPU {
 /* if set, limit maximum value for phys_bits when host_phys_bits is true */
 uint8_t host_phys_bits_limit;
 
-/* Stop SMI delivery for migration compatibility with old machines */
-bool kvm_no_smi_migration;
-
 /* Forcefully disable KVM PV features not exposed in guest CPUIDs */
 bool kvm_pv_enforce_cpuid;
 
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 33760a2ee1..f9991e7398 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -7905,8 +7905,6 @@ static Property x86_cpu_properties[] = {
 DEFINE_PROP_BOOL("x-vendor-cpuid-only", X86CPU, vendor_cpuid_only, true),
 DEFINE_PROP_BOOL("lmce", X86CPU, enable_lmce, false),
 DEFINE_PROP_BOOL("l3-cache", X86CPU, enable_l3_cache, true),
-DEFINE_PROP_BOOL("kvm-no-smi-migration", X86CPU, kvm_no_smi_migration,
- false),
 DEFINE_PROP_BOOL("kvm-pv-enforce-cpuid", X86CPU, kvm_pv_enforce_cpuid,
  false),
 DEFINE_PROP_BOOL("vmware-cpuid-freq", X86CPU, vmware_cpuid_freq, true),
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index e68cbe9293..88f4a7da33 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -4337,6 +4337,7 @@ static int kvm_put_vcpu_events(X86CPU *cpu, int level)
 events.sipi_vector = env->sipi_vector;
 
 if (has_msr_smbase) {
+events.flags |= KVM_VCPUEVENT_VALID_SMM;
 events.smi.smm = !!(env->hflags & HF_SMM_MASK);
 events.smi.smm_inside_nmi = !!(env->hflags2 & HF2_SMM_INSIDE_NMI_MASK);
 if (kvm_irqchip_in_kernel()) {
@@ -4351,12 +4352,6 @@ static int kvm_put_vcpu_events(X86CPU *cpu, int level)
 events.smi.pending = 0;
 events.smi.latched_init = 0;
 }
-/* Stop SMI delivery on old machine types to avoid a reboot
- * on an inward migration of an old VM.
- */
-if (!cpu->kvm_no_smi_migration) {
-events.flags |= KVM_VCPUEVENT_VALID_SMM;
-}
 }
 
 if (level >= KVM_PUT_RESET_STATE) {
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 19/21] hw/i386/pc: Remove 2.3 and deprecate 2.4 to 2.7 pc-i440fx machines

2024-03-27 Thread Philippe Mathieu-Daudé
The pc-i440fx-2.3 machine was deprecated for the 8.2
release (see commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
time to remove it. Similarly to the cited commit,
deprecate the 2.4 to 2.7 machines.

Signed-off-by: Philippe Mathieu-Daudé 
---
 docs/about/deprecated.rst   |  6 +++---
 docs/about/removed-features.rst |  2 +-
 hw/i386/pc.c| 25 -
 hw/i386/pc_piix.c   | 20 
 4 files changed, 4 insertions(+), 49 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index f6eac988c0..22335ef6b0 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -219,10 +219,10 @@ deprecated; use the new name ``dtb-randomness`` instead. 
The new name
 better reflects the way this property affects all random data within
 the device tree blob, not just the ``kaslr-seed`` node.
 
-``pc-i440fx-2.3`` (since 8.2)
-'
+``pc-i440fx-2.4`` up to ``pc-i440fx-2.7`` (since 9.1)
+'
 
-This old machine type is quite neglected nowadays and thus might have
+These old machine types are quite neglected nowadays and thus might have
 various pitfalls with regards to live migration. Use a newer machine type
 instead.
 
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index 4664974a8b..0caa6a63e4 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -816,7 +816,7 @@ mips ``fulong2e`` machine alias (removed in 6.0)
 
 This machine has been renamed ``fuloong2e``.
 
-``pc-0.10`` up to ``pc-i440fx-2.2`` (removed in 4.0 up to 9.0)
+``pc-0.10`` up to ``pc-i440fx-2.3`` (removed in 4.0 up to 9.0)
 ''
 
 These machine types were very old and likely could not be used for live
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 5fd83010ba..27e04c52f6 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -256,31 +256,6 @@ GlobalProperty pc_compat_2_4[] = {
 };
 const size_t pc_compat_2_4_len = G_N_ELEMENTS(pc_compat_2_4);
 
-GlobalProperty pc_compat_2_3[] = {
-PC_CPU_MODEL_IDS("2.3.0")
-{ TYPE_X86_CPU, "arat", "off" },
-{ "qemu64" "-" TYPE_X86_CPU, "min-level", "4" },
-{ "kvm64" "-" TYPE_X86_CPU, "min-level", "5" },
-{ "pentium3" "-" TYPE_X86_CPU, "min-level", "2" },
-{ "n270" "-" TYPE_X86_CPU, "min-level", "5" },
-{ "Conroe" "-" TYPE_X86_CPU, "min-level", "4" },
-{ "Penryn" "-" TYPE_X86_CPU, "min-level", "4" },
-{ "Nehalem" "-" TYPE_X86_CPU, "min-level", "4" },
-{ "n270" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Penryn" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Conroe" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Nehalem" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Westmere" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "SandyBridge" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "IvyBridge" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Haswell" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Haswell-noTSX" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Broadwell" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ "Broadwell-noTSX" "-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
-{ TYPE_X86_CPU, "kvm-no-smi-migration", "on" },
-};
-const size_t pc_compat_2_3_len = G_N_ELEMENTS(pc_compat_2_3);
-
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
 {
 GSIState *s;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 9615e25d56..c00d2a66a6 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -421,14 +421,6 @@ static void pc_set_south_bridge(Object *obj, int value, 
Error **errp)
  * hw_compat_*, pc_compat_*, or * pc_*_machine_options().
  */
 
-static void pc_compat_2_3_fn(MachineState *machine)
-{
-X86MachineState *x86ms = X86_MACHINE(machine);
-if (kvm_enabled()) {
-x86ms->smm = ON_OFF_AUTO_OFF;
-}
-}
-
 #ifdef CONFIG_ISAPC
 static void pc_init_isa(MachineState *machine)
 {
@@ -811,18 +803,6 @@ static void pc_i440fx_2_4_machine_options(MachineClass *m)
 DEFINE_I440FX_MACHINE(v2_4, "pc-i440fx-2.4", NULL,
   pc_i440fx_2_4_machine_options)
 
-static void pc_i440fx_2_3_machine_options(MachineClass *m)
-{
-pc_i440fx_2_4_machine_options(m);
-m->hw_version = "2.3.0";
-m->deprecation_reason = "old and unattended - use a newer version instead";
-compat_props_add(m->compat_props, hw_compat_2_3, hw_compat_2_3_len);
-compat_props_add(m->compat_props, pc_compat_2_3, pc_compat_2_3_len);
-}
-
-DEFINE_I440FX_MACHINE(v2_3, "pc-i440fx-2.3", pc_compat_2_3_fn,
-  pc_i440fx_2_3_machine_options);
-
 #ifdef CONFIG_ISAPC
 static void isapc_machine_options(MachineClass *m)
 {
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To 

[PATCH-for-9.1 v2 18/21] hw/i386/acpi: Remove AcpiBuildState::rsdp field

2024-03-27 Thread Philippe Mathieu-Daudé
AcpiBuildState::rsdp is always NULL, remove it,
simplifying acpi_build_update().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-16-phi...@linaro.org>
---
 hw/i386/acpi-build.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index ed0adb0e82..6f9925d176 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2459,7 +2459,6 @@ struct AcpiBuildState {
 MemoryRegion *table_mr;
 /* Is table patched? */
 uint8_t patched;
-void *rsdp;
 MemoryRegion *rsdp_mr;
 MemoryRegion *linker_mr;
 } AcpiBuildState;
@@ -2715,11 +2714,7 @@ static void acpi_build_update(void *build_opaque)
 
 acpi_ram_update(build_state->table_mr, tables.table_data);
 
-if (build_state->rsdp) {
-memcpy(build_state->rsdp, tables.rsdp->data, 
acpi_data_len(tables.rsdp));
-} else {
-acpi_ram_update(build_state->rsdp_mr, tables.rsdp);
-}
+acpi_ram_update(build_state->rsdp_mr, tables.rsdp);
 
 acpi_ram_update(build_state->linker_mr, tables.linker->cmd_blob);
 acpi_build_tables_cleanup(, true);
@@ -2805,7 +2800,6 @@ void acpi_setup(void)
tables.vmgenid);
 }
 
-build_state->rsdp = NULL;
 build_state->rsdp_mr = acpi_add_rom_blob(acpi_build_update,
  build_state, tables.rsdp,
  ACPI_BUILD_RSDP_FILE);
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 17/21] hw/i386/pc: Remove PCMachineClass::rsdp_in_ram

2024-03-27 Thread Philippe Mathieu-Daudé
PCMachineClass::rsdp_in_ram was only used by the
pc-i440fx-2.2 machine, which got removed. It is
now always true. Remove it, simplifying acpi_setup().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-15-phi...@linaro.org>
---
 include/hw/i386/pc.h |  1 -
 hw/i386/acpi-build.c | 35 ---
 hw/i386/pc.c |  1 -
 3 files changed, 4 insertions(+), 33 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 10a8ffa0de..96ccb4583f 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -100,7 +100,6 @@ struct PCMachineClass {
 
 /* ACPI compat: */
 bool has_acpi_build;
-bool rsdp_in_ram;
 unsigned acpi_data_size;
 int pci_root_uid;
 
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index ab2d4d8dcb..ed0adb0e82 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2495,7 +2495,6 @@ static
 void acpi_build(AcpiBuildTables *tables, MachineState *machine)
 {
 PCMachineState *pcms = PC_MACHINE(machine);
-PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 X86MachineState *x86ms = X86_MACHINE(machine);
 DeviceState *iommu = pcms->iommu;
 GArray *table_offsets;
@@ -2667,16 +2666,6 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
 .rsdt_tbl_offset = ,
 };
 build_rsdp(tables->rsdp, tables->linker, _data);
-if (!pcmc->rsdp_in_ram) {
-/* We used to allocate some extra space for RSDP revision 2 but
- * only used the RSDP revision 0 space. The extra bytes were
- * zeroed out and not used.
- * Here we continue wasting those extra 16 bytes to make sure we
- * don't break migration for machine types 2.2 and older due to
- * RSDP blob size mismatch.
- */
-build_append_int_noprefix(tables->rsdp, 0, 16);
-}
 }
 
 /* We'll expose it all to Guest so we want to reduce
@@ -2755,7 +2744,6 @@ static const VMStateDescription vmstate_acpi_build = {
 void acpi_setup(void)
 {
 PCMachineState *pcms = PC_MACHINE(qdev_get_machine());
-PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 X86MachineState *x86ms = X86_MACHINE(pcms);
 AcpiBuildTables tables;
 AcpiBuildState *build_state;
@@ -2817,25 +2805,10 @@ void acpi_setup(void)
tables.vmgenid);
 }
 
-if (!pcmc->rsdp_in_ram) {
-/*
- * Keep for compatibility with old machine types.
- * Though RSDP is small, its contents isn't immutable, so
- * we'll update it along with the rest of tables on guest access.
- */
-uint32_t rsdp_size = acpi_data_len(tables.rsdp);
-
-build_state->rsdp = g_memdup(tables.rsdp->data, rsdp_size);
-fw_cfg_add_file_callback(x86ms->fw_cfg, ACPI_BUILD_RSDP_FILE,
- acpi_build_update, NULL, build_state,
- build_state->rsdp, rsdp_size, true);
-build_state->rsdp_mr = NULL;
-} else {
-build_state->rsdp = NULL;
-build_state->rsdp_mr = acpi_add_rom_blob(acpi_build_update,
- build_state, tables.rsdp,
- ACPI_BUILD_RSDP_FILE);
-}
+build_state->rsdp = NULL;
+build_state->rsdp_mr = acpi_add_rom_blob(acpi_build_update,
+ build_state, tables.rsdp,
+ ACPI_BUILD_RSDP_FILE);
 
 qemu_register_reset(acpi_build_reset, build_state);
 acpi_build_reset(build_state);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index ae2d220269..5fd83010ba 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1743,7 +1743,6 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 
 pcmc->pci_enabled = true;
 pcmc->has_acpi_build = true;
-pcmc->rsdp_in_ram = true;
 pcmc->smbios_defaults = true;
 pcmc->gigabyte_align = true;
 pcmc->has_reserved_memory = true;
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 16/21] hw/i386/pc: Remove PCMachineClass::resizable_acpi_blob

2024-03-27 Thread Philippe Mathieu-Daudé
PCMachineClass::resizable_acpi_blob was only used by the
pc-i440fx-2.2 machine, which got removed. It is now always
true. Remove it, simplifying acpi_build().

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h |  3 ---
 hw/i386/acpi-build.c | 10 --
 hw/i386/pc.c |  1 -
 3 files changed, 14 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index df97df6ca7..10a8ffa0de 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -124,9 +124,6 @@ struct PCMachineClass {
 /* create kvmclock device even when KVM PV features are not exposed */
 bool kvmclock_create_always;
 
-/* resizable acpi blob compat */
-bool resizable_acpi_blob;
-
 /*
  * whether the machine type implements broken 32-bit address space bound
  * check for memory.
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a6f8203460..ab2d4d8dcb 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2688,16 +2688,6 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
  * keep the table size stable for all (max_cpus, max_memory_slots)
  * combinations.
  */
-/* Make sure we have a buffer in case we need to resize the tables. */
-if ((tables_blob->len > ACPI_BUILD_TABLE_SIZE / 2) &&
-!pcmc->resizable_acpi_blob) {
-/* As of QEMU 2.1, this fires with 160 VCPUs and 255 memory slots.  */
-warn_report("ACPI table size %u exceeds %d bytes,"
-" migration may not work",
-tables_blob->len, ACPI_BUILD_TABLE_SIZE / 2);
-error_printf("Try removing CPUs, NUMA nodes, memory slots"
- " or PCI bridges.\n");
-}
 acpi_align_size(tables_blob, ACPI_BUILD_TABLE_SIZE);
 
 acpi_align_size(tables->linker->cmd_blob, ACPI_BUILD_ALIGN_SIZE);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index c37d813af0..ae2d220269 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1753,7 +1753,6 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 pcmc->acpi_data_size = 0x2 + 0x8000;
 pcmc->pvh_enabled = true;
 pcmc->kvmclock_create_always = true;
-pcmc->resizable_acpi_blob = true;
 x86mc->apic_xrupt_override = true;
 assert(!mc->get_hotplug_handler);
 mc->get_hotplug_handler = pc_get_hotplug_handler;
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 15/21] hw/i386/pc: Remove deprecated pc-i440fx-2.2 machine

2024-03-27 Thread Philippe Mathieu-Daudé
The pc-i440fx-2.2 machine was deprecated for the 8.2
release (see commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
time to remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-13-phi...@linaro.org>
---
 docs/about/deprecated.rst   |  6 +++---
 docs/about/removed-features.rst |  2 +-
 include/hw/i386/pc.h|  3 ---
 hw/i386/pc.c| 23 ---
 hw/i386/pc_piix.c   | 21 -
 5 files changed, 4 insertions(+), 51 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index deadcc044f..f6eac988c0 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -219,10 +219,10 @@ deprecated; use the new name ``dtb-randomness`` instead. 
The new name
 better reflects the way this property affects all random data within
 the device tree blob, not just the ``kaslr-seed`` node.
 
-``pc-i440fx-2.2`` up to ``pc-i440fx-2.3`` (since 8.2)
-'
+``pc-i440fx-2.3`` (since 8.2)
+'
 
-These old machine types are quite neglected nowadays and thus might have
+This old machine type is quite neglected nowadays and thus might have
 various pitfalls with regards to live migration. Use a newer machine type
 instead.
 
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index 01c55103d3..4664974a8b 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -816,7 +816,7 @@ mips ``fulong2e`` machine alias (removed in 6.0)
 
 This machine has been renamed ``fuloong2e``.
 
-``pc-0.10`` up to ``pc-i440fx-2.1`` (removed in 4.0 up to 9.0)
+``pc-0.10`` up to ``pc-i440fx-2.2`` (removed in 4.0 up to 9.0)
 ''
 
 These machine types were very old and likely could not be used for live
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 231aae92ed..df97df6ca7 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -274,9 +274,6 @@ extern const size_t pc_compat_2_4_len;
 extern GlobalProperty pc_compat_2_3[];
 extern const size_t pc_compat_2_3_len;
 
-extern GlobalProperty pc_compat_2_2[];
-extern const size_t pc_compat_2_2_len;
-
 #define DEFINE_PC_MACHINE(suffix, namestr, initfn, optsfn) \
 static void pc_machine_##suffix##_class_init(ObjectClass *oc, void *data) \
 { \
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 44283d3165..c37d813af0 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -281,29 +281,6 @@ GlobalProperty pc_compat_2_3[] = {
 };
 const size_t pc_compat_2_3_len = G_N_ELEMENTS(pc_compat_2_3);
 
-GlobalProperty pc_compat_2_2[] = {
-PC_CPU_MODEL_IDS("2.2.0")
-{ "kvm64" "-" TYPE_X86_CPU, "vme", "off" },
-{ "kvm32" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Conroe" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Penryn" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Nehalem" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Westmere" "-" TYPE_X86_CPU, "vme", "off" },
-{ "SandyBridge" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Haswell" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Broadwell" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Opteron_G1" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Opteron_G2" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Opteron_G3" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Opteron_G4" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Opteron_G5" "-" TYPE_X86_CPU, "vme", "off" },
-{ "Haswell" "-" TYPE_X86_CPU, "f16c", "off" },
-{ "Haswell" "-" TYPE_X86_CPU, "rdrand", "off" },
-{ "Broadwell" "-" TYPE_X86_CPU, "f16c", "off" },
-{ "Broadwell" "-" TYPE_X86_CPU, "rdrand", "off" },
-};
-const size_t pc_compat_2_2_len = G_N_ELEMENTS(pc_compat_2_2);
-
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
 {
 GSIState *s;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 02f3bce4f3..9615e25d56 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -429,11 +429,6 @@ static void pc_compat_2_3_fn(MachineState *machine)
 }
 }
 
-static void pc_compat_2_2_fn(MachineState *machine)
-{
-pc_compat_2_3_fn(machine);
-}
-
 #ifdef CONFIG_ISAPC
 static void pc_init_isa(MachineState *machine)
 {
@@ -828,22 +823,6 @@ static void pc_i440fx_2_3_machine_options(MachineClass *m)
 DEFINE_I440FX_MACHINE(v2_3, "pc-i440fx-2.3", pc_compat_2_3_fn,
   pc_i440fx_2_3_machine_options);
 
-static void pc_i440fx_2_2_machine_options(MachineClass *m)
-{
-PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
-
-pc_i440fx_2_3_machine_options(m);
-m->hw_version = "2.2.0";
-m->default_machine_opts = "firmware=bios-256k.bin,suppress-vmdesc=on";
-compat_props_add(m->compat_props, hw_compat_2_2, hw_compat_2_2_len);
-compat_props_add(m->compat_props, pc_compat_2_2, pc_compat_2_2_len);
-pcmc->rsdp_in_ram = false;
-pcmc->resizable_acpi_blob = false;
-}
-

[PATCH-for-9.1 v2 14/21] hw/mem/memory-device: Remove legacy_align from memory_device_pre_plug()

2024-03-27 Thread Philippe Mathieu-Daudé
'legacy_align' is always NULL, remove it, simplifying
memory_device_pre_plug().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-12-phi...@linaro.org>
---
 include/hw/mem/memory-device.h |  2 +-
 hw/i386/pc.c   |  3 +--
 hw/mem/memory-device.c | 12 
 hw/mem/pc-dimm.c   |  2 +-
 hw/virtio/virtio-md-pci.c  |  2 +-
 5 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/include/hw/mem/memory-device.h b/include/hw/mem/memory-device.h
index e0571c8a31..c0a58087cc 100644
--- a/include/hw/mem/memory-device.h
+++ b/include/hw/mem/memory-device.h
@@ -169,7 +169,7 @@ uint64_t get_plugged_memory_size(void);
 unsigned int memory_devices_get_reserved_memslots(void);
 bool memory_devices_memslot_auto_decision_active(void);
 void memory_device_pre_plug(MemoryDeviceState *md, MachineState *ms,
-const uint64_t *legacy_align, Error **errp);
+Error **errp);
 void memory_device_plug(MemoryDeviceState *md, MachineState *ms);
 void memory_device_unplug(MemoryDeviceState *md, MachineState *ms);
 uint64_t memory_device_get_region_size(const MemoryDeviceState *md,
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index baa1b228a9..44283d3165 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1377,8 +1377,7 @@ static void pc_hv_balloon_pre_plug(HotplugHandler 
*hotplug_dev,
 {
 /* The vmbus handler has no hotplug handler; we should never end up here. 
*/
 g_assert(!dev->hotplugged);
-memory_device_pre_plug(MEMORY_DEVICE(dev), MACHINE(hotplug_dev), NULL,
-   errp);
+memory_device_pre_plug(MEMORY_DEVICE(dev), MACHINE(hotplug_dev), errp);
 }
 
 static void pc_hv_balloon_plug(HotplugHandler *hotplug_dev,
diff --git a/hw/mem/memory-device.c b/hw/mem/memory-device.c
index e098585cda..a5f279adcc 100644
--- a/hw/mem/memory-device.c
+++ b/hw/mem/memory-device.c
@@ -345,7 +345,7 @@ uint64_t get_plugged_memory_size(void)
 }
 
 void memory_device_pre_plug(MemoryDeviceState *md, MachineState *ms,
-const uint64_t *legacy_align, Error **errp)
+Error **errp)
 {
 const MemoryDeviceClass *mdc = MEMORY_DEVICE_GET_CLASS(md);
 Error *local_err = NULL;
@@ -388,14 +388,10 @@ void memory_device_pre_plug(MemoryDeviceState *md, 
MachineState *ms,
 return;
 }
 
-if (legacy_align) {
-align = *legacy_align;
-} else {
-if (mdc->get_min_alignment) {
-align = mdc->get_min_alignment(md);
-}
-align = MAX(align, memory_region_get_alignment(mr));
+if (mdc->get_min_alignment) {
+align = mdc->get_min_alignment(md);
 }
+align = MAX(align, memory_region_get_alignment(mr));
 addr = mdc->get_addr(md);
 addr = memory_device_get_free_addr(ms, !addr ? NULL : , align,
memory_region_size(mr), _err);
diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index 836384a90f..27919ca45d 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -69,7 +69,7 @@ void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState 
*machine, Error **errp)
 _abort);
 trace_mhp_pc_dimm_assigned_slot(slot);
 
-memory_device_pre_plug(MEMORY_DEVICE(dimm), machine, NULL, errp);
+memory_device_pre_plug(MEMORY_DEVICE(dimm), machine, errp);
 }
 
 void pc_dimm_plug(PCDIMMDevice *dimm, MachineState *machine)
diff --git a/hw/virtio/virtio-md-pci.c b/hw/virtio/virtio-md-pci.c
index 62bfb7920b..9ec5067662 100644
--- a/hw/virtio/virtio-md-pci.c
+++ b/hw/virtio/virtio-md-pci.c
@@ -37,7 +37,7 @@ void virtio_md_pci_pre_plug(VirtIOMDPCI *vmd, MachineState 
*ms, Error **errp)
  * First, see if we can plug this memory device at all. If that
  * succeeds, branch of to the actual hotplug handler.
  */
-memory_device_pre_plug(md, ms, NULL, _err);
+memory_device_pre_plug(md, ms, _err);
 if (!local_err && bus_handler) {
 hotplug_handler_pre_plug(bus_handler, dev, _err);
 }
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 13/21] hw/mem/pc-dimm: Remove legacy_align argument from pc_dimm_pre_plug()

2024-03-27 Thread Philippe Mathieu-Daudé
'legacy_align' is always NULL, remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-11-phi...@linaro.org>
---
 include/hw/mem/pc-dimm.h | 3 +--
 hw/arm/virt.c| 2 +-
 hw/i386/pc.c | 2 +-
 hw/loongarch/virt.c  | 2 +-
 hw/mem/pc-dimm.c | 6 ++
 hw/ppc/spapr.c   | 2 +-
 6 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/include/hw/mem/pc-dimm.h b/include/hw/mem/pc-dimm.h
index 322bebe555..fe0f3ea963 100644
--- a/include/hw/mem/pc-dimm.h
+++ b/include/hw/mem/pc-dimm.h
@@ -66,8 +66,7 @@ struct PCDIMMDeviceClass {
 void (*unrealize)(PCDIMMDevice *dimm);
 };
 
-void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState *machine,
-  const uint64_t *legacy_align, Error **errp);
+void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState *machine, Error **errp);
 void pc_dimm_plug(PCDIMMDevice *dimm, MachineState *machine);
 void pc_dimm_unplug(PCDIMMDevice *dimm, MachineState *machine);
 #endif
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index a55ef916cb..7af05a6a2d 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -2736,7 +2736,7 @@ static void virt_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
-pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), NULL, errp);
+pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), errp);
 }
 
 static void virt_memory_plug(HotplugHandler *hotplug_dev,
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index adbc43ab90..baa1b228a9 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1309,7 +1309,7 @@ static void pc_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
-pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), NULL, errp);
+pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), errp);
 }
 
 static void pc_memory_plug(HotplugHandler *hotplug_dev,
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index 00d3005e54..af71bd2a99 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -1025,7 +1025,7 @@ static bool memhp_type_supported(DeviceState *dev)
 static void virt_mem_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
  Error **errp)
 {
-pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), NULL, errp);
+pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), errp);
 }
 
 static void virt_machine_device_pre_plug(HotplugHandler *hotplug_dev,
diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index 37f1f4ccfd..836384a90f 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -44,8 +44,7 @@ static MemoryRegion *pc_dimm_get_memory_region(PCDIMMDevice 
*dimm, Error **errp)
 return host_memory_backend_get_memory(dimm->hostmem);
 }
 
-void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState *machine,
-  const uint64_t *legacy_align, Error **errp)
+void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState *machine, Error **errp)
 {
 Error *local_err = NULL;
 int slot;
@@ -70,8 +69,7 @@ void pc_dimm_pre_plug(PCDIMMDevice *dimm, MachineState 
*machine,
 _abort);
 trace_mhp_pc_dimm_assigned_slot(slot);
 
-memory_device_pre_plug(MEMORY_DEVICE(dimm), machine, legacy_align,
-   errp);
+memory_device_pre_plug(MEMORY_DEVICE(dimm), machine, NULL, errp);
 }
 
 void pc_dimm_plug(PCDIMMDevice *dimm, MachineState *machine)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index c417f9dd52..770b49456a 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -3667,7 +3667,7 @@ static void spapr_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
-pc_dimm_pre_plug(dimm, MACHINE(hotplug_dev), NULL, errp);
+pc_dimm_pre_plug(dimm, MACHINE(hotplug_dev), errp);
 }
 
 struct SpaprDimmState {
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 12/21] hw/i386/pc: Remove PCMachineClass::enforce_aligned_dimm

2024-03-27 Thread Philippe Mathieu-Daudé
PCMachineClass::enforce_aligned_dimm was only used by the
pc-i440fx-2.1 machine, which got removed. It is now always
true. Remove it, simplifying pc_get_device_memory_range().
Update the comment in Avocado test_phybits_low_pse36().

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h  |  3 ---
 hw/i386/pc.c  | 14 +++---
 tests/avocado/mem-addr-space-check.py |  3 +--
 3 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index c2d9af36b2..231aae92ed 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -74,8 +74,6 @@ typedef struct PCMachineState {
  *
  * Compat fields:
  *
- * @enforce_aligned_dimm: check that DIMM's address/size is aligned by
- *backend's alignment value if provided
  * @acpi_data_size: Size of the chunk of memory at the top of RAM
  *  for the BIOS ACPI tables and other BIOS
  *  datastructures.
@@ -114,7 +112,6 @@ struct PCMachineClass {
 /* RAM / address space compat: */
 bool gigabyte_align;
 bool has_reserved_memory;
-bool enforce_aligned_dimm;
 bool broken_reserved_end;
 bool enforce_amd_1tb_hole;
 
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index f9650a2821..adbc43ab90 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -716,7 +716,6 @@ static void pc_get_device_memory_range(PCMachineState *pcms,
hwaddr *base,
ram_addr_t *device_mem_size)
 {
-PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 MachineState *machine = MACHINE(pcms);
 ram_addr_t size;
 hwaddr addr;
@@ -724,10 +723,8 @@ static void pc_get_device_memory_range(PCMachineState 
*pcms,
 size = machine->maxram_size - machine->ram_size;
 addr = ROUND_UP(pc_above_4g_end(pcms), 1 * GiB);
 
-if (pcmc->enforce_aligned_dimm) {
-/* size device region assuming 1G page max alignment per slot */
-size += (1 * GiB) * machine->ram_slots;
-}
+/* size device region assuming 1G page max alignment per slot */
+size += (1 * GiB) * machine->ram_slots;
 
 *base = addr;
 *device_mem_size = size;
@@ -1285,12 +1282,9 @@ void pc_i8259_create(ISABus *isa_bus, qemu_irq 
*i8259_irqs)
 static void pc_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
Error **errp)
 {
-const PCMachineState *pcms = PC_MACHINE(hotplug_dev);
 const X86MachineState *x86ms = X86_MACHINE(hotplug_dev);
-const PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 const MachineState *ms = MACHINE(hotplug_dev);
 const bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
-const uint64_t legacy_align = TARGET_PAGE_SIZE;
 Error *local_err = NULL;
 
 /*
@@ -1315,8 +1309,7 @@ static void pc_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
-pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev),
- pcmc->enforce_aligned_dimm ? NULL : _align, errp);
+pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), NULL, errp);
 }
 
 static void pc_memory_plug(HotplugHandler *hotplug_dev,
@@ -1778,7 +1771,6 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 pcmc->smbios_defaults = true;
 pcmc->gigabyte_align = true;
 pcmc->has_reserved_memory = true;
-pcmc->enforce_aligned_dimm = true;
 pcmc->enforce_amd_1tb_hole = true;
 /* BIOS ACPI tables: 128K. Other BIOS datastructures: less than 4K reported
  * to be used at the moment, 32K should be enough for a while.  */
diff --git a/tests/avocado/mem-addr-space-check.py 
b/tests/avocado/mem-addr-space-check.py
index af019969c0..ad75170d52 100644
--- a/tests/avocado/mem-addr-space-check.py
+++ b/tests/avocado/mem-addr-space-check.py
@@ -31,8 +31,7 @@ def test_phybits_low_pse36(self):
 at 4 GiB boundary when "above_4g_mem_size" is 0 (this would be true 
when
 we have 0.5 GiB of VM memory, see pc_q35_init()). This means total
 hotpluggable memory size is 60 GiB. Per slot, we reserve 1 GiB of 
memory
-for dimm alignment for all newer machines (see enforce_aligned_dimm
-property for pc machines and pc_get_device_memory_range()). That leaves
+for dimm alignment for all machines. That leaves
 total hotpluggable actual memory size of 59 GiB. If the VM is started
 with 0.5 GiB of memory, maxmem should be set to a maximum value of
 59.5 GiB to ensure that the processor can address all memory directly.
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 11/21] hw/smbios: Remove 'smbios_uuid_encoded', simplify smbios_encode_uuid()

2024-03-27 Thread Philippe Mathieu-Daudé
'smbios_encode_uuid' is always true, remove it,
simplifying smbios_encode_uuid().

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/smbios/smbios.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index 8261eb716f..3b7703489d 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -30,7 +30,6 @@
 #include "hw/pci/pci_device.h"
 #include "smbios_build.h"
 
-static const bool smbios_uuid_encoded = true;
 /*
  * SMBIOS tables provided by user with '-smbios file=' option
  */
@@ -600,11 +599,9 @@ static void smbios_build_type_0_table(void)
 static void smbios_encode_uuid(struct smbios_uuid *uuid, QemuUUID *in)
 {
 memcpy(uuid, in, 16);
-if (smbios_uuid_encoded) {
-uuid->time_low = bswap32(uuid->time_low);
-uuid->time_mid = bswap16(uuid->time_mid);
-uuid->time_hi_and_version = bswap16(uuid->time_hi_and_version);
-}
+uuid->time_low = bswap32(uuid->time_low);
+uuid->time_mid = bswap16(uuid->time_mid);
+uuid->time_hi_and_version = bswap16(uuid->time_hi_and_version);
 }
 
 static void smbios_build_type_1_table(void)
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 10/21] hw/smbios: Remove 'uuid_encoded' argument from smbios_set_defaults()

2024-03-27 Thread Philippe Mathieu-Daudé
'uuid_encoded' is always NULL, remove it.

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/firmware/smbios.h | 3 +--
 hw/arm/virt.c| 3 +--
 hw/i386/fw_cfg.c | 2 +-
 hw/loongarch/virt.c  | 2 +-
 hw/riscv/virt.c  | 2 +-
 hw/smbios/smbios.c   | 6 ++
 6 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
index 8d3fb2fb3b..f066ab7262 100644
--- a/include/hw/firmware/smbios.h
+++ b/include/hw/firmware/smbios.h
@@ -331,8 +331,7 @@ void smbios_add_usr_blob_size(size_t size);
 void smbios_entry_add(QemuOpts *opts, Error **errp);
 void smbios_set_cpuid(uint32_t version, uint32_t features);
 void smbios_set_defaults(const char *manufacturer, const char *product,
- const char *version,
- bool uuid_encoded);
+ const char *version);
 void smbios_set_default_processor_family(uint16_t processor_family);
 uint8_t *smbios_get_table_legacy(size_t *length, Error **errp);
 void smbios_get_tables(MachineState *ms,
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index a9a913aead..a55ef916cb 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1650,8 +1650,7 @@ static void virt_build_smbios(VirtMachineState *vms)
 }
 
 smbios_set_defaults("QEMU", product,
-vmc->smbios_old_sys_ver ? "1.0" : mc->name,
-true);
+vmc->smbios_old_sys_ver ? "1.0" : mc->name);
 
 /* build the array of physical mem area from base_memmap */
 mem_array.address = vms->memmap[VIRT_MEM].base;
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index f7c2501161..ecc4047a4b 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -63,7 +63,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState 
*fw_cfg,
 
 if (pcmc->smbios_defaults) {
 /* These values are guest ABI, do not change */
-smbios_set_defaults("QEMU", mc->desc, mc->name, true);
+smbios_set_defaults("QEMU", mc->desc, mc->name);
 }
 
 /* tell smbios about cpuid version and features */
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index 441d764843..00d3005e54 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -355,7 +355,7 @@ static void virt_build_smbios(LoongArchMachineState *lams)
 return;
 }
 
-smbios_set_defaults("QEMU", product, mc->name, true);
+smbios_set_defaults("QEMU", product, mc->name);
 
 smbios_get_tables(ms, SMBIOS_ENTRY_POINT_TYPE_64,
   NULL, 0,
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index d171e74f7b..1ed9b0552e 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -1277,7 +1277,7 @@ static void virt_build_smbios(RISCVVirtState *s)
 product = "KVM Virtual Machine";
 }
 
-smbios_set_defaults("QEMU", product, mc->name, true);
+smbios_set_defaults("QEMU", product, mc->name);
 
 if (riscv_is_32bit(>soc[0])) {
 smbios_set_default_processor_family(0x200);
diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index eed5787b15..8261eb716f 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -30,7 +30,7 @@
 #include "hw/pci/pci_device.h"
 #include "smbios_build.h"
 
-static bool smbios_uuid_encoded = true;
+static const bool smbios_uuid_encoded = true;
 /*
  * SMBIOS tables provided by user with '-smbios file=' option
  */
@@ -1017,11 +1017,9 @@ void smbios_set_default_processor_family(uint16_t 
processor_family)
 }
 
 void smbios_set_defaults(const char *manufacturer, const char *product,
- const char *version,
- bool uuid_encoded)
+ const char *version)
 {
 smbios_have_defaults = true;
-smbios_uuid_encoded = uuid_encoded;
 
 SMBIOS_SET_DEFAULT(smbios_type1.manufacturer, manufacturer);
 SMBIOS_SET_DEFAULT(smbios_type1.product, product);
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 09/21] hw/i386/pc: Remove PCMachineClass::smbios_uuid_encoded

2024-03-27 Thread Philippe Mathieu-Daudé
PCMachineClass::smbios_uuid_encoded was only used by the
pc-i440fx-2.1 machine, which got removed. It is now always
true, remove it.

Reviewed-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h | 1 -
 hw/i386/fw_cfg.c | 3 +--
 hw/i386/pc.c | 1 -
 3 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index b528f17904..c2d9af36b2 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -109,7 +109,6 @@ struct PCMachineClass {
 /* SMBIOS compat: */
 bool smbios_defaults;
 bool smbios_legacy_mode;
-bool smbios_uuid_encoded;
 SmbiosEntryPointType default_smbios_ep_type;
 
 /* RAM / address space compat: */
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index d802d2787f..f7c2501161 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -63,8 +63,7 @@ void fw_cfg_build_smbios(PCMachineState *pcms, FWCfgState 
*fw_cfg,
 
 if (pcmc->smbios_defaults) {
 /* These values are guest ABI, do not change */
-smbios_set_defaults("QEMU", mc->desc, mc->name,
-pcmc->smbios_uuid_encoded);
+smbios_set_defaults("QEMU", mc->desc, mc->name, true);
 }
 
 /* tell smbios about cpuid version and features */
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 21a19f9f9f..f9650a2821 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1776,7 +1776,6 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 pcmc->has_acpi_build = true;
 pcmc->rsdp_in_ram = true;
 pcmc->smbios_defaults = true;
-pcmc->smbios_uuid_encoded = true;
 pcmc->gigabyte_align = true;
 pcmc->has_reserved_memory = true;
 pcmc->enforce_aligned_dimm = true;
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 08/21] target/i386/kvm: Remove x86_cpu_change_kvm_default() and 'kvm-cpu.h'

2024-03-27 Thread Philippe Mathieu-Daudé
x86_cpu_change_kvm_default() was only used out of kvm-cpu.c by
the pc-i440fx-2.1 machine, which got removed. Make it static,
and remove its declaration. "kvm-cpu.h" is now empty, remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-8-phi...@linaro.org>
---
 target/i386/kvm/kvm-cpu.h | 41 ---
 target/i386/kvm/kvm-cpu.c |  3 +--
 2 files changed, 1 insertion(+), 43 deletions(-)
 delete mode 100644 target/i386/kvm/kvm-cpu.h

diff --git a/target/i386/kvm/kvm-cpu.h b/target/i386/kvm/kvm-cpu.h
deleted file mode 100644
index e858ca21e5..00
--- a/target/i386/kvm/kvm-cpu.h
+++ /dev/null
@@ -1,41 +0,0 @@
-/*
- * i386 KVM CPU type and functions
- *
- *  Copyright (c) 2003 Fabrice Bellard
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2 of the License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, see .
- */
-
-#ifndef KVM_CPU_H
-#define KVM_CPU_H
-
-#ifdef CONFIG_KVM
-/*
- * Change the value of a KVM-specific default
- *
- * If value is NULL, no default will be set and the original
- * value from the CPU model table will be kept.
- *
- * It is valid to call this function only for properties that
- * are already present in the kvm_default_props table.
- */
-void x86_cpu_change_kvm_default(const char *prop, const char *value);
-
-#else /* !CONFIG_KVM */
-
-#define x86_cpu_change_kvm_default(a, b)
-
-#endif /* CONFIG_KVM */
-
-#endif /* KVM_CPU_H */
diff --git a/target/i386/kvm/kvm-cpu.c b/target/i386/kvm/kvm-cpu.c
index 9c791b7b05..cb8c73d20c 100644
--- a/target/i386/kvm/kvm-cpu.c
+++ b/target/i386/kvm/kvm-cpu.c
@@ -10,7 +10,6 @@
 #include "qemu/osdep.h"
 #include "cpu.h"
 #include "host-cpu.h"
-#include "kvm-cpu.h"
 #include "qapi/error.h"
 #include "sysemu/sysemu.h"
 #include "hw/boards.h"
@@ -144,7 +143,7 @@ static PropValue kvm_default_props[] = {
 /*
  * Only for builtin_x86_defs models initialized with x86_register_cpudef_types.
  */
-void x86_cpu_change_kvm_default(const char *prop, const char *value)
+static void x86_cpu_change_kvm_default(const char *prop, const char *value)
 {
 PropValue *pv;
 for (pv = kvm_default_props; pv->prop; pv++) {
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 07/21] hw/i386/pc: Remove deprecated pc-i440fx-2.1 machine

2024-03-27 Thread Philippe Mathieu-Daudé
The pc-i440fx-2.1 machine was deprecated for the 8.2
release (see commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
time to remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-7-phi...@linaro.org>
---
 docs/about/deprecated.rst   |  2 +-
 docs/about/removed-features.rst |  2 +-
 include/hw/i386/pc.h|  3 ---
 hw/i386/pc.c|  7 ---
 hw/i386/pc_piix.c   | 23 ---
 5 files changed, 2 insertions(+), 35 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index b567415d62..deadcc044f 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -219,7 +219,7 @@ deprecated; use the new name ``dtb-randomness`` instead. 
The new name
 better reflects the way this property affects all random data within
 the device tree blob, not just the ``kaslr-seed`` node.
 
-``pc-i440fx-2.1`` up to ``pc-i440fx-2.3`` (since 8.2)
+``pc-i440fx-2.2`` up to ``pc-i440fx-2.3`` (since 8.2)
 '
 
 These old machine types are quite neglected nowadays and thus might have
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index 51119e623f..01c55103d3 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -816,7 +816,7 @@ mips ``fulong2e`` machine alias (removed in 6.0)
 
 This machine has been renamed ``fuloong2e``.
 
-``pc-0.10`` up to ``pc-i440fx-2.0`` (removed in 4.0 up to 9.0)
+``pc-0.10`` up to ``pc-i440fx-2.1`` (removed in 4.0 up to 9.0)
 ''
 
 These machine types were very old and likely could not be used for live
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 4ad724601a..b528f17904 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -281,9 +281,6 @@ extern const size_t pc_compat_2_3_len;
 extern GlobalProperty pc_compat_2_2[];
 extern const size_t pc_compat_2_2_len;
 
-extern GlobalProperty pc_compat_2_1[];
-extern const size_t pc_compat_2_1_len;
-
 #define DEFINE_PC_MACHINE(suffix, namestr, initfn, optsfn) \
 static void pc_machine_##suffix##_class_init(ObjectClass *oc, void *data) \
 { \
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index e7b6abf237..21a19f9f9f 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -304,13 +304,6 @@ GlobalProperty pc_compat_2_2[] = {
 };
 const size_t pc_compat_2_2_len = G_N_ELEMENTS(pc_compat_2_2);
 
-GlobalProperty pc_compat_2_1[] = {
-PC_CPU_MODEL_IDS("2.1.0")
-{ "coreduo" "-" TYPE_X86_CPU, "vmx", "on" },
-{ "core2duo" "-" TYPE_X86_CPU, "vmx", "on" },
-};
-const size_t pc_compat_2_1_len = G_N_ELEMENTS(pc_compat_2_1);
-
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
 {
 GSIState *s;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 585231ef7b..02f3bce4f3 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -66,7 +66,6 @@
 #include "hw/hyperv/vmbus-bridge.h"
 #include "hw/mem/nvdimm.h"
 #include "hw/i386/acpi-build.h"
-#include "kvm/kvm-cpu.h"
 #include "target/i386/cpu.h"
 
 #define XEN_IOAPIC_NUM_PIRQS 128ULL
@@ -435,12 +434,6 @@ static void pc_compat_2_2_fn(MachineState *machine)
 pc_compat_2_3_fn(machine);
 }
 
-static void pc_compat_2_1_fn(MachineState *machine)
-{
-pc_compat_2_2_fn(machine);
-x86_cpu_change_kvm_default("svm", NULL);
-}
-
 #ifdef CONFIG_ISAPC
 static void pc_init_isa(MachineState *machine)
 {
@@ -851,22 +844,6 @@ static void pc_i440fx_2_2_machine_options(MachineClass *m)
 DEFINE_I440FX_MACHINE(v2_2, "pc-i440fx-2.2", pc_compat_2_2_fn,
   pc_i440fx_2_2_machine_options);
 
-static void pc_i440fx_2_1_machine_options(MachineClass *m)
-{
-PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
-
-pc_i440fx_2_2_machine_options(m);
-m->hw_version = "2.1.0";
-m->default_display = NULL;
-compat_props_add(m->compat_props, hw_compat_2_1, hw_compat_2_1_len);
-compat_props_add(m->compat_props, pc_compat_2_1, pc_compat_2_1_len);
-pcmc->smbios_uuid_encoded = false;
-pcmc->enforce_aligned_dimm = false;
-}
-
-DEFINE_I440FX_MACHINE(v2_1, "pc-i440fx-2.1", pc_compat_2_1_fn,
-  pc_i440fx_2_1_machine_options);
-
 #ifdef CONFIG_ISAPC
 static void isapc_machine_options(MachineClass *m)
 {
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 06/21] hw/acpi/ich9: Remove dead code related to 'acpi_memory_hotplug'

2024-03-27 Thread Philippe Mathieu-Daudé
acpi_memory_hotplug::is_enabled is set to %true once via
ich9_lpc_initfn() -> ich9_pm_add_properties(). No need to
check it, so remove now dead code.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/acpi/ich9.c | 28 ++--
 1 file changed, 6 insertions(+), 22 deletions(-)

diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 9b605af21a..02d8546bd3 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -153,17 +153,10 @@ static int ich9_pm_post_load(void *opaque, int version_id)
  .offset = vmstate_offset_pointer(_state, _field, uint8_t),  \
  }
 
-static bool vmstate_test_use_memhp(void *opaque)
-{
-ICH9LPCPMRegs *s = opaque;
-return s->acpi_memory_hotplug.is_enabled;
-}
-
 static const VMStateDescription vmstate_memhp_state = {
 .name = "ich9_pm/memhp",
 .version_id = 1,
 .minimum_version_id = 1,
-.needed = vmstate_test_use_memhp,
 .fields = (const VMStateField[]) {
 VMSTATE_MEMORY_HOTPLUG(acpi_memory_hotplug, ICH9LPCPMRegs),
 VMSTATE_END_OF_LIST()
@@ -335,11 +328,9 @@ void ich9_pm_init(PCIDevice *lpc_pci, ICH9LPCPMRegs *pm, 
qemu_irq sci_irq)
 legacy_acpi_cpu_hotplug_init(pci_address_space_io(lpc_pci),
 OBJECT(lpc_pci), >gpe_cpu, ICH9_CPU_HOTPLUG_IO_BASE);
 
-if (pm->acpi_memory_hotplug.is_enabled) {
-acpi_memory_hotplug_init(pci_address_space_io(lpc_pci), 
OBJECT(lpc_pci),
- >acpi_memory_hotplug,
- ACPI_MEMORY_HOTPLUG_BASE);
-}
+acpi_memory_hotplug_init(pci_address_space_io(lpc_pci), OBJECT(lpc_pci),
+ >acpi_memory_hotplug,
+ ACPI_MEMORY_HOTPLUG_BASE);
 }
 
 static void ich9_pm_get_gpe0_blk(Object *obj, Visitor *v, const char *name,
@@ -460,12 +451,7 @@ void ich9_pm_device_pre_plug_cb(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
-if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) &&
-!lpc->pm.acpi_memory_hotplug.is_enabled) {
-error_setg(errp,
-   "memory hotplug is not enabled: %s.memory-hotplug-support "
-   "is not set", object_get_typename(OBJECT(lpc)));
-} else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
 uint64_t negotiated = lpc->smi_negotiated_features;
 
 if (negotiated & BIT_ULL(ICH9_LPC_SMI_F_BROADCAST_BIT) &&
@@ -509,8 +495,7 @@ void ich9_pm_device_unplug_request_cb(HotplugHandler 
*hotplug_dev,
 {
 ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
 
-if (lpc->pm.acpi_memory_hotplug.is_enabled &&
-object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
 acpi_memory_unplug_request_cb(hotplug_dev,
   >pm.acpi_memory_hotplug, dev,
   errp);
@@ -545,8 +530,7 @@ void ich9_pm_device_unplug_cb(HotplugHandler *hotplug_dev, 
DeviceState *dev,
 {
 ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
 
-if (lpc->pm.acpi_memory_hotplug.is_enabled &&
-object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
 acpi_memory_unplug_cb(>pm.acpi_memory_hotplug, dev, errp);
 } else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU) &&
!lpc->pm.cpu_hotplug_legacy) {
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 05/21] hw/acpi/ich9: Remove 'memory-hotplug-support' property

2024-03-27 Thread Philippe Mathieu-Daudé
No external code sets the 'memory-hotplug-support'
property, remove it.

Suggested-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/acpi/ich9.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 573d032e8e..9b605af21a 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -351,21 +351,6 @@ static void ich9_pm_get_gpe0_blk(Object *obj, Visitor *v, 
const char *name,
 visit_type_uint32(v, name, , errp);
 }
 
-static bool ich9_pm_get_memory_hotplug_support(Object *obj, Error **errp)
-{
-ICH9LPCState *s = ICH9_LPC_DEVICE(obj);
-
-return s->pm.acpi_memory_hotplug.is_enabled;
-}
-
-static void ich9_pm_set_memory_hotplug_support(Object *obj, bool value,
-   Error **errp)
-{
-ICH9LPCState *s = ICH9_LPC_DEVICE(obj);
-
-s->pm.acpi_memory_hotplug.is_enabled = value;
-}
-
 static bool ich9_pm_get_cpu_hotplug_legacy(Object *obj, Error **errp)
 {
 ICH9LPCState *s = ICH9_LPC_DEVICE(obj);
@@ -445,9 +430,6 @@ void ich9_pm_add_properties(Object *obj, ICH9LPCPMRegs *pm)
 NULL, NULL, pm);
 object_property_add_uint32_ptr(obj, ACPI_PM_PROP_GPE0_BLK_LEN,
_len, OBJ_PROP_FLAG_READ);
-object_property_add_bool(obj, "memory-hotplug-support",
- ich9_pm_get_memory_hotplug_support,
- ich9_pm_set_memory_hotplug_support);
 object_property_add_bool(obj, "cpu-hotplug-legacy",
  ich9_pm_get_cpu_hotplug_legacy,
  ich9_pm_set_cpu_hotplug_legacy);
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 04/21] hw/i386/acpi: Remove PCMachineClass::legacy_acpi_table_size

2024-03-27 Thread Philippe Mathieu-Daudé
PCMachineClass::legacy_acpi_table_size was only used by the
pc-i440fx-2.0 machine, which got removed. Remove it and simplify
acpi_build().

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/i386/pc.h |  1 -
 hw/i386/acpi-build.c | 62 +---
 2 files changed, 12 insertions(+), 51 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 67856f54c3..4ad724601a 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -103,7 +103,6 @@ struct PCMachineClass {
 /* ACPI compat: */
 bool has_acpi_build;
 bool rsdp_in_ram;
-int legacy_acpi_table_size;
 unsigned acpi_data_size;
 int pci_root_uid;
 
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 53f804ac16..a6f8203460 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2499,13 +2499,12 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
 X86MachineState *x86ms = X86_MACHINE(machine);
 DeviceState *iommu = pcms->iommu;
 GArray *table_offsets;
-unsigned facs, dsdt, rsdt, fadt;
+unsigned facs, dsdt, rsdt;
 AcpiPmInfo pm;
 AcpiMiscInfo misc;
 AcpiMcfgInfo mcfg;
 Range pci_hole = {}, pci_hole64 = {};
 uint8_t *u;
-size_t aml_len = 0;
 GArray *tables_blob = tables->table_data;
 AcpiSlicOem slic_oem = { .id = NULL, .table_id = NULL };
 Object *vmgenid_dev;
@@ -2551,19 +2550,12 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
 build_dsdt(tables_blob, tables->linker, , ,
_hole, _hole64, machine);
 
-/* Count the size of the DSDT and SSDT, we will need it for legacy
- * sizing of ACPI tables.
- */
-aml_len += tables_blob->len - dsdt;
-
 /* ACPI tables pointed to by RSDT */
-fadt = tables_blob->len;
 acpi_add_table(table_offsets, tables_blob);
 pm.fadt.facs_tbl_offset = 
 pm.fadt.dsdt_tbl_offset = 
 pm.fadt.xdsdt_tbl_offset = 
 build_fadt(tables_blob, tables->linker, , oem_id, oem_table_id);
-aml_len += tables_blob->len - fadt;
 
 acpi_add_table(table_offsets, tables_blob);
 acpi_build_madt(tables_blob, tables->linker, x86ms,
@@ -2694,49 +2686,19 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
  * too simple to be enough.  4k turned out to be too small an
  * alignment very soon, and in fact it is almost impossible to
  * keep the table size stable for all (max_cpus, max_memory_slots)
- * combinations.  So the table size is always 64k for pc-i440fx-2.1
- * and we give an error if the table grows beyond that limit.
- *
- * We still have the problem of migrating from "-M pc-i440fx-2.0".  For
- * that, we exploit the fact that QEMU 2.1 generates _smaller_ tables
- * than 2.0 and we can always pad the smaller tables with zeros.  We can
- * then use the exact size of the 2.0 tables.
- *
- * All this is for PIIX4, since QEMU 2.0 didn't support Q35 migration.
+ * combinations.
  */
-if (pcmc->legacy_acpi_table_size) {
-/* Subtracting aml_len gives the size of fixed tables.  Then add the
- * size of the PIIX4 DSDT/SSDT in QEMU 2.0.
- */
-int legacy_aml_len =
-pcmc->legacy_acpi_table_size +
-ACPI_BUILD_LEGACY_CPU_AML_SIZE * x86ms->apic_id_limit;
-int legacy_table_size =
-ROUND_UP(tables_blob->len - aml_len + legacy_aml_len,
- ACPI_BUILD_ALIGN_SIZE);
-if ((tables_blob->len > legacy_table_size) &&
-!pcmc->resizable_acpi_blob) {
-/* Should happen only with PCI bridges and -M pc-i440fx-2.0.  */
-warn_report("ACPI table size %u exceeds %d bytes,"
-" migration may not work",
-tables_blob->len, legacy_table_size);
-error_printf("Try removing CPUs, NUMA nodes, memory slots"
- " or PCI bridges.\n");
-}
-g_array_set_size(tables_blob, legacy_table_size);
-} else {
-/* Make sure we have a buffer in case we need to resize the tables. */
-if ((tables_blob->len > ACPI_BUILD_TABLE_SIZE / 2) &&
-!pcmc->resizable_acpi_blob) {
-/* As of QEMU 2.1, this fires with 160 VCPUs and 255 memory slots. 
 */
-warn_report("ACPI table size %u exceeds %d bytes,"
-" migration may not work",
-tables_blob->len, ACPI_BUILD_TABLE_SIZE / 2);
-error_printf("Try removing CPUs, NUMA nodes, memory slots"
- " or PCI bridges.\n");
-}
-acpi_align_size(tables_blob, ACPI_BUILD_TABLE_SIZE);
+/* Make sure we have a buffer in case we need to resize the tables. */
+if ((tables_blob->len > ACPI_BUILD_TABLE_SIZE / 2) &&
+!pcmc->resizable_acpi_blob) {
+/* As of QEMU 2.1, this fires with 160 VCPUs and 255 memory slots.  */
+warn_report("ACPI table size %u 

[PATCH-for-9.1 v2 03/21] hw/usb/hcd-xhci: Remove XHCI_FLAG_SS_FIRST flag

2024-03-27 Thread Philippe Mathieu-Daudé
XHCI_FLAG_SS_FIRST was only used by the pc-i440fx-2.0 machine,
which got removed. Remove it and simplify various functions in
hcd-xhci.c.

Reviewed-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/usb/hcd-xhci.h |  3 +--
 hw/usb/hcd-xhci-nec.c |  2 --
 hw/usb/hcd-xhci-pci.c |  1 -
 hw/usb/hcd-xhci.c | 42 --
 4 files changed, 9 insertions(+), 39 deletions(-)

diff --git a/hw/usb/hcd-xhci.h b/hw/usb/hcd-xhci.h
index 1efa4858fb..fe16d7ad05 100644
--- a/hw/usb/hcd-xhci.h
+++ b/hw/usb/hcd-xhci.h
@@ -36,8 +36,7 @@ typedef struct XHCIStreamContext XHCIStreamContext;
 typedef struct XHCIEPContext XHCIEPContext;
 
 enum xhci_flags {
-XHCI_FLAG_SS_FIRST = 1,
-XHCI_FLAG_ENABLE_STREAMS,
+XHCI_FLAG_ENABLE_STREAMS = 1,
 };
 
 typedef enum TRBType {
diff --git a/hw/usb/hcd-xhci-nec.c b/hw/usb/hcd-xhci-nec.c
index 5d5b069cf9..0c063b3697 100644
--- a/hw/usb/hcd-xhci-nec.c
+++ b/hw/usb/hcd-xhci-nec.c
@@ -41,8 +41,6 @@ struct XHCINecState {
 static Property nec_xhci_properties[] = {
 DEFINE_PROP_ON_OFF_AUTO("msi", XHCIPciState, msi, ON_OFF_AUTO_AUTO),
 DEFINE_PROP_ON_OFF_AUTO("msix", XHCIPciState, msix, ON_OFF_AUTO_AUTO),
-DEFINE_PROP_BIT("superspeed-ports-first", XHCINecState, flags,
-XHCI_FLAG_SS_FIRST, true),
 DEFINE_PROP_UINT32("intrs", XHCINecState, intrs, XHCI_MAXINTRS),
 DEFINE_PROP_UINT32("slots", XHCINecState, slots, XHCI_MAXSLOTS),
 DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/usb/hcd-xhci-pci.c b/hw/usb/hcd-xhci-pci.c
index cbad96f393..264d7ebb77 100644
--- a/hw/usb/hcd-xhci-pci.c
+++ b/hw/usb/hcd-xhci-pci.c
@@ -242,7 +242,6 @@ static void qemu_xhci_instance_init(Object *obj)
 s->msix = ON_OFF_AUTO_AUTO;
 xhci->numintrs = XHCI_MAXINTRS;
 xhci->numslots = XHCI_MAXSLOTS;
-xhci_set_flag(xhci, XHCI_FLAG_SS_FIRST);
 }
 
 static const TypeInfo qemu_xhci_info = {
diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index ad40232eb6..b6411f0bda 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -541,18 +541,10 @@ static XHCIPort *xhci_lookup_port(XHCIState *xhci, struct 
USBPort *uport)
 case USB_SPEED_LOW:
 case USB_SPEED_FULL:
 case USB_SPEED_HIGH:
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-index = uport->index + xhci->numports_3;
-} else {
-index = uport->index;
-}
+index = uport->index + xhci->numports_3;
 break;
 case USB_SPEED_SUPER:
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-index = uport->index;
-} else {
-index = uport->index + xhci->numports_2;
-}
+index = uport->index;
 break;
 default:
 return NULL;
@@ -2779,11 +2771,7 @@ static uint64_t xhci_cap_read(void *ptr, hwaddr reg, 
unsigned size)
 ret = 0x20425355; /* "USB " */
 break;
 case 0x28: /* Supported Protocol:08 */
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-ret = (xhci->numports_2<<8) | (xhci->numports_3+1);
-} else {
-ret = (xhci->numports_2<<8) | 1;
-}
+ret = (xhci->numports_2 << 8) | (xhci->numports_3 + 1);
 break;
 case 0x2c: /* Supported Protocol:0c */
 ret = 0x; /* reserved */
@@ -2795,11 +2783,7 @@ static uint64_t xhci_cap_read(void *ptr, hwaddr reg, 
unsigned size)
 ret = 0x20425355; /* "USB " */
 break;
 case 0x38: /* Supported Protocol:08 */
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-ret = (xhci->numports_3<<8) | 1;
-} else {
-ret = (xhci->numports_3<<8) | (xhci->numports_2+1);
-}
+ret = (xhci->numports_3 << 8) | 1;
 break;
 case 0x3c: /* Supported Protocol:0c */
 ret = 0x; /* reserved */
@@ -3349,13 +,8 @@ static void usb_xhci_init(XHCIState *xhci)
 for (i = 0; i < usbports; i++) {
 speedmask = 0;
 if (i < xhci->numports_2) {
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-port = >ports[i + xhci->numports_3];
-port->portnr = i + 1 + xhci->numports_3;
-} else {
-port = >ports[i];
-port->portnr = i + 1;
-}
+port = >ports[i + xhci->numports_3];
+port->portnr = i + 1 + xhci->numports_3;
 port->uport = >uports[i];
 port->speedmask =
 USB_SPEED_MASK_LOW  |
@@ -3366,13 +3345,8 @@ static void usb_xhci_init(XHCIState *xhci)
 speedmask |= port->speedmask;
 }
 if (i < xhci->numports_3) {
-if (xhci_get_flag(xhci, XHCI_FLAG_SS_FIRST)) {
-port = >ports[i];
-port->portnr = i + 1;
-} else {
-port = >ports[i + xhci->numports_2];
-port->portnr = i + 1 + xhci->numports_2;
-}
+port = >ports[i];
+port->portnr = 

[PATCH-for-9.1 v2 02/21] hw/usb/hcd-xhci: Remove XHCI_FLAG_FORCE_PCIE_ENDCAP flag

2024-03-27 Thread Philippe Mathieu-Daudé
XHCI_FLAG_FORCE_PCIE_ENDCAP was only used by the
pc-i440fx-2.0 machine, which got removed. Remove it
and simplify usb_xhci_pci_realize().

Reviewed-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/usb/hcd-xhci.h | 1 -
 hw/usb/hcd-xhci-nec.c | 2 --
 hw/usb/hcd-xhci-pci.c | 3 +--
 3 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/hw/usb/hcd-xhci.h b/hw/usb/hcd-xhci.h
index 98f598382a..1efa4858fb 100644
--- a/hw/usb/hcd-xhci.h
+++ b/hw/usb/hcd-xhci.h
@@ -37,7 +37,6 @@ typedef struct XHCIEPContext XHCIEPContext;
 
 enum xhci_flags {
 XHCI_FLAG_SS_FIRST = 1,
-XHCI_FLAG_FORCE_PCIE_ENDCAP,
 XHCI_FLAG_ENABLE_STREAMS,
 };
 
diff --git a/hw/usb/hcd-xhci-nec.c b/hw/usb/hcd-xhci-nec.c
index 328e5bfe7c..5d5b069cf9 100644
--- a/hw/usb/hcd-xhci-nec.c
+++ b/hw/usb/hcd-xhci-nec.c
@@ -43,8 +43,6 @@ static Property nec_xhci_properties[] = {
 DEFINE_PROP_ON_OFF_AUTO("msix", XHCIPciState, msix, ON_OFF_AUTO_AUTO),
 DEFINE_PROP_BIT("superspeed-ports-first", XHCINecState, flags,
 XHCI_FLAG_SS_FIRST, true),
-DEFINE_PROP_BIT("force-pcie-endcap", XHCINecState, flags,
-XHCI_FLAG_FORCE_PCIE_ENDCAP, false),
 DEFINE_PROP_UINT32("intrs", XHCINecState, intrs, XHCI_MAXINTRS),
 DEFINE_PROP_UINT32("slots", XHCINecState, slots, XHCI_MAXSLOTS),
 DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/usb/hcd-xhci-pci.c b/hw/usb/hcd-xhci-pci.c
index 4423983308..cbad96f393 100644
--- a/hw/usb/hcd-xhci-pci.c
+++ b/hw/usb/hcd-xhci-pci.c
@@ -148,8 +148,7 @@ static void usb_xhci_pci_realize(struct PCIDevice *dev, 
Error **errp)
  PCI_BASE_ADDRESS_MEM_TYPE_64,
  >xhci.mem);
 
-if (pci_bus_is_express(pci_get_bus(dev)) ||
-xhci_get_flag(>xhci, XHCI_FLAG_FORCE_PCIE_ENDCAP)) {
+if (pci_bus_is_express(pci_get_bus(dev))) {
 ret = pcie_endpoint_cap_init(dev, 0xa0);
 assert(ret > 0);
 }
-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


[PATCH-for-9.1 v2 01/21] hw/i386/pc: Remove deprecated pc-i440fx-2.0 machine

2024-03-27 Thread Philippe Mathieu-Daudé
The pc-i440fx-2.0 machine was deprecated for the 8.2
release (see commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
time to remove it.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Message-Id: <20240305134221.30924-2-phi...@linaro.org>
---
 docs/about/deprecated.rst   |  2 +-
 docs/about/removed-features.rst |  2 +-
 include/hw/i386/pc.h|  3 ---
 hw/i386/pc.c| 15 -
 hw/i386/pc_piix.c   | 37 -
 5 files changed, 2 insertions(+), 57 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 7b548519b5..b567415d62 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -219,7 +219,7 @@ deprecated; use the new name ``dtb-randomness`` instead. 
The new name
 better reflects the way this property affects all random data within
 the device tree blob, not just the ``kaslr-seed`` node.
 
-``pc-i440fx-2.0`` up to ``pc-i440fx-2.3`` (since 8.2)
+``pc-i440fx-2.1`` up to ``pc-i440fx-2.3`` (since 8.2)
 '
 
 These old machine types are quite neglected nowadays and thus might have
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index f9cf874f7b..51119e623f 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -816,7 +816,7 @@ mips ``fulong2e`` machine alias (removed in 6.0)
 
 This machine has been renamed ``fuloong2e``.
 
-``pc-0.10`` up to ``pc-i440fx-1.7`` (removed in 4.0 up to 8.2)
+``pc-0.10`` up to ``pc-i440fx-2.0`` (removed in 4.0 up to 9.0)
 ''
 
 These machine types were very old and likely could not be used for live
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 27a68071d7..67856f54c3 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -285,9 +285,6 @@ extern const size_t pc_compat_2_2_len;
 extern GlobalProperty pc_compat_2_1[];
 extern const size_t pc_compat_2_1_len;
 
-extern GlobalProperty pc_compat_2_0[];
-extern const size_t pc_compat_2_0_len;
-
 #define DEFINE_PC_MACHINE(suffix, namestr, initfn, optsfn) \
 static void pc_machine_##suffix##_class_init(ObjectClass *oc, void *data) \
 { \
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index e80f02bef4..e7b6abf237 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -311,21 +311,6 @@ GlobalProperty pc_compat_2_1[] = {
 };
 const size_t pc_compat_2_1_len = G_N_ELEMENTS(pc_compat_2_1);
 
-GlobalProperty pc_compat_2_0[] = {
-PC_CPU_MODEL_IDS("2.0.0")
-{ "virtio-scsi-pci", "any_layout", "off" },
-{ "PIIX4_PM", "memory-hotplug-support", "off" },
-{ "apic", "version", "0x11" },
-{ "nec-usb-xhci", "superspeed-ports-first", "off" },
-{ "nec-usb-xhci", "force-pcie-endcap", "on" },
-{ "pci-serial", "prog_if", "0" },
-{ "pci-serial-2x", "prog_if", "0" },
-{ "pci-serial-4x", "prog_if", "0" },
-{ "virtio-net-pci", "guest_announce", "off" },
-{ "ICH9-LPC", "memory-hotplug-support", "off" },
-};
-const size_t pc_compat_2_0_len = G_N_ELEMENTS(pc_compat_2_0);
-
 GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
 {
 GSIState *s;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 18ba076609..585231ef7b 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -441,11 +441,6 @@ static void pc_compat_2_1_fn(MachineState *machine)
 x86_cpu_change_kvm_default("svm", NULL);
 }
 
-static void pc_compat_2_0_fn(MachineState *machine)
-{
-pc_compat_2_1_fn(machine);
-}
-
 #ifdef CONFIG_ISAPC
 static void pc_init_isa(MachineState *machine)
 {
@@ -872,38 +867,6 @@ static void pc_i440fx_2_1_machine_options(MachineClass *m)
 DEFINE_I440FX_MACHINE(v2_1, "pc-i440fx-2.1", pc_compat_2_1_fn,
   pc_i440fx_2_1_machine_options);
 
-static void pc_i440fx_2_0_machine_options(MachineClass *m)
-{
-PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
-
-pc_i440fx_2_1_machine_options(m);
-m->hw_version = "2.0.0";
-compat_props_add(m->compat_props, pc_compat_2_0, pc_compat_2_0_len);
-pcmc->smbios_legacy_mode = true;
-pcmc->has_reserved_memory = false;
-/* This value depends on the actual DSDT and SSDT compiled into
- * the source QEMU; unfortunately it depends on the binary and
- * not on the machine type, so we cannot make pc-i440fx-1.7 work on
- * both QEMU 1.7 and QEMU 2.0.
- *
- * Large variations cause migration to fail for more than one
- * consecutive value of the "-smp" maxcpus option.
- *
- * For small variations of the kind caused by different iasl versions,
- * the 4k rounding usually leaves slack.  However, there could be still
- * one or two values that break.  For QEMU 1.7 and QEMU 2.0 the
- * slack is only ~10 bytes before one "-smp maxcpus" value breaks!
- *
- * 6652 is valid for QEMU 2.0, the right value for pc-i440fx-1.7 on
- * 

[PATCH-for-9.1 v2 00/21] hw/i386: Remove deprecated pc-i440fx-2.0 -> 2.3 machines

2024-03-27 Thread Philippe Mathieu-Daudé
Missing review: 4-6, 10-12, 16, 19-20

Since v1:
- Addressed Zhao and Thomas review comments
- Removal around ICH9 acpi_memory_hotplug (Thomas)

Kill legacy code, because we need to evolve.

I ended there via dynamic machine -> ICH9 -> legacy ACPI...

This should also help Igor cleanups:
http://lore.kernel.org/qemu-devel/20240326171632.3cc75...@imammedo.users.ipa.redhat.com/

Philippe Mathieu-Daudé (21):
  hw/i386/pc: Remove deprecated pc-i440fx-2.0 machine
  hw/usb/hcd-xhci: Remove XHCI_FLAG_FORCE_PCIE_ENDCAP flag
  hw/usb/hcd-xhci: Remove XHCI_FLAG_SS_FIRST flag
  hw/i386/acpi: Remove PCMachineClass::legacy_acpi_table_size
  hw/acpi/ich9: Remove 'memory-hotplug-support' property
  hw/acpi/ich9: Remove dead code related to 'acpi_memory_hotplug'
  hw/i386/pc: Remove deprecated pc-i440fx-2.1 machine
  target/i386/kvm: Remove x86_cpu_change_kvm_default() and 'kvm-cpu.h'
  hw/i386/pc: Remove PCMachineClass::smbios_uuid_encoded
  hw/smbios: Remove 'uuid_encoded' argument from smbios_set_defaults()
  hw/smbios: Remove 'smbios_uuid_encoded', simplify smbios_encode_uuid()
  hw/i386/pc: Remove PCMachineClass::enforce_aligned_dimm
  hw/mem/pc-dimm: Remove legacy_align argument from pc_dimm_pre_plug()
  hw/mem/memory-device: Remove legacy_align from
memory_device_pre_plug()
  hw/i386/pc: Remove deprecated pc-i440fx-2.2 machine
  hw/i386/pc: Remove PCMachineClass::resizable_acpi_blob
  hw/i386/pc: Remove PCMachineClass::rsdp_in_ram
  hw/i386/acpi: Remove AcpiBuildState::rsdp field
  hw/i386/pc: Remove 2.3 and deprecate 2.4 to 2.7 pc-i440fx machines
  target/i386: Remove X86CPU::kvm_no_smi_migration field
  hw/i386/pc: Replace PCMachineClass::acpi_data_size by
PC_ACPI_DATA_SIZE

 docs/about/deprecated.rst |   2 +-
 docs/about/removed-features.rst   |   2 +-
 hw/usb/hcd-xhci.h |   4 +-
 include/hw/firmware/smbios.h  |   3 +-
 include/hw/i386/pc.h  |  22 --
 include/hw/mem/memory-device.h|   2 +-
 include/hw/mem/pc-dimm.h  |   3 +-
 target/i386/cpu.h |   3 -
 target/i386/kvm/kvm-cpu.h |  41 --
 hw/acpi/ich9.c|  46 ++-
 hw/arm/virt.c |   5 +-
 hw/i386/acpi-build.c  |  95 ++-
 hw/i386/fw_cfg.c  |   3 +-
 hw/i386/pc.c  | 107 --
 hw/i386/pc_piix.c | 101 
 hw/loongarch/virt.c   |   4 +-
 hw/mem/memory-device.c|  12 +--
 hw/mem/pc-dimm.c  |   6 +-
 hw/ppc/spapr.c|   2 +-
 hw/riscv/virt.c   |   2 +-
 hw/smbios/smbios.c|  13 +---
 hw/usb/hcd-xhci-nec.c |   4 -
 hw/usb/hcd-xhci-pci.c |   4 +-
 hw/usb/hcd-xhci.c |  42 ++
 hw/virtio/virtio-md-pci.c |   2 +-
 target/i386/cpu.c |   2 -
 target/i386/kvm/kvm-cpu.c |   3 +-
 target/i386/kvm/kvm.c |   7 +-
 tests/avocado/mem-addr-space-check.py |   3 +-
 29 files changed, 64 insertions(+), 481 deletions(-)
 delete mode 100644 target/i386/kvm/kvm-cpu.h

-- 
2.41.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH-for-9.1 17/18] target/i386: Remove X86CPU::kvm_no_smi_migration field

2024-03-27 Thread Philippe Mathieu-Daudé

On 6/3/24 19:30, Thomas Huth wrote:

On 05/03/2024 14.42, Philippe Mathieu-Daudé wrote:

X86CPU::kvm_no_smi_migration was only used by the
pc-i440fx-2.3 machine, which got removed. Remove it
and simplify kvm_put_vcpu_events().

Signed-off-by: Philippe Mathieu-Daudé 
---
  target/i386/cpu.h | 3 ---
  target/i386/cpu.c | 2 --
  target/i386/kvm/kvm.c | 6 --
  3 files changed, 11 deletions(-)




diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 42970ab046..571cbbf1fc 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -4344,12 +4344,6 @@ static int kvm_put_vcpu_events(X86CPU *cpu, int 
level)

  events.smi.pending = 0;
  events.smi.latched_init = 0;
  }
-    /* Stop SMI delivery on old machine types to avoid a reboot
- * on an inward migration of an old VM.
- */
-    if (!cpu->kvm_no_smi_migration) {
-    events.flags |= KVM_VCPUEVENT_VALID_SMM;
-    }


Shouldn't it be the other way round, i.e. that the flag is now always set?


Oops you are right, good catch!



pc_compat_2_3[] had:

     { TYPE_X86_CPU, "kvm-no-smi-migration", "on" },

... so I think kvm_no_smi_migration was set to true for the old machines?

  Thomas


___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH-for-9.1 01/18] hw/i386/pc: Remove deprecated pc-i440fx-2.0 machine

2024-03-27 Thread Philippe Mathieu-Daudé

On 6/3/24 17:41, Thomas Huth wrote:

On 05/03/2024 14.42, Philippe Mathieu-Daudé wrote:

The pc-i440fx-2.0 machine was deprecated for the 8.2
release (see commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
time to remove it.

Signed-off-by: Philippe Mathieu-Daudé 
---
  docs/about/deprecated.rst   |  2 +-
  docs/about/removed-features.rst |  2 +-
  include/hw/i386/pc.h    |  3 ---
  hw/i386/pc.c    | 15 -
  hw/i386/pc_piix.c   | 37 -
  5 files changed, 2 insertions(+), 57 deletions(-)




diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index f5ff970acf..bb7ef31af2 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -311,21 +311,6 @@ GlobalProperty pc_compat_2_1[] = {
  };
  const size_t pc_compat_2_1_len = G_N_ELEMENTS(pc_compat_2_1);
-GlobalProperty pc_compat_2_0[] = {
-    PC_CPU_MODEL_IDS("2.0.0")
-    { "virtio-scsi-pci", "any_layout", "off" },
-    { "PIIX4_PM", "memory-hotplug-support", "off" },
-    { "apic", "version", "0x11" },
-    { "nec-usb-xhci", "superspeed-ports-first", "off" },
-    { "nec-usb-xhci", "force-pcie-endcap", "on" },
-    { "pci-serial", "prog_if", "0" },
-    { "pci-serial-2x", "prog_if", "0" },
-    { "pci-serial-4x", "prog_if", "0" },
-    { "virtio-net-pci", "guest_announce", "off" },
-    { "ICH9-LPC", "memory-hotplug-support", "off" },


I think you could clean up memory-hotplug-support for the ICH9-LPC 
device now, too (in a separate patch).


Great suggestion, thanks!



For this patch here:
Reviewed-by: Thomas Huth 


___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org


Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated

2024-03-27 Thread Gerd Hoffmann
On Tue, Mar 26, 2024 at 01:30:48PM +, Mark Cave-Ayland wrote:
> Heh I've actually been using isapc over the past couple of weeks to fire up
> some old programs in a Windows 3 VM :)

I'm wondering why these use cases can't simply use the 'pc' machine
type?

The early pci chipsets of the 90-ies have been designed in a
backward-compatible manner, with devices such as the IDE controller
being mapped to the standard ISA ioports.  So even an historic OS which
does not know what PCI is can run on that hardware, by simply talking to
devices using the standard ISA io ports ...

take care,
  Gerd
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org