Re: [PATCH v19 02/21] s390x/cpu topology: add topology entries on CPU hotplug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 4/24/23 17:32, Nina Schoetterl-Glausch wrote:
On Fri, 2023-04-21 at 12:20 +0200, Pierre Morel wrote:
On 4/20/23 10:59, Nina Schoetterl-Glausch wrote:
On Mon, 2023-04-03 at 18:28 +0200, Pierre Morel wrote:
[..]
In the next version with entitlement being an enum it is right.

However, deleting this means that the default value for entitlement
depends on dedication.

If we have only low, medium, high and default for entitlement is medium.

If the user specifies the dedication true without specifying entitlement
we could force entitlement to high.

But we can not distinguish this from the user specifying dedication true
with a medium entitlement, which is wrong.

So three solution:

1) We ignore what the user say if dedication is specified as true

2) We specify that both dedication and entitlement must be specified if
dedication is true

3) We set an impossible default to distinguish default from medium
entitlement


For me the solution 3 is the best one, it is more flexible for the user.

Solution 1 is obviously bad.

Solution 2 forces the user to specify entitlement high and only high if
it specifies dedication true.

AFAIU, you prefer the solution 2, forcing user to specify both
dedication and entitlement to suppress a default value in the enum.
Why is it bad to have a default value in the enum that we do not use to
specify that the value must be calculated?
Yes, I'd prefer solution 2. I don't like adapting the internal state where only
the three values make sense for the user interface.
It also keeps things simple and requires less code.
I also don't think it's a bad thing for the user, as it's not a thing done manually often.
I'm also not a fan of a value being implicitly being changed even though it doesn't look
like it from the command.

However, what I really don't like is the additional state and naming it "horizontal",


No problem to use another name like "auto" as you propose later.


not so much the adjustment if dedication is switched to true without an entitlement given.
For the monitor command there is no problem, you currently have:


That is clear, the has_xxx does the job.

[..]


So you can just set it if (!has_entitlement).
There is also ways to set the value for cpus defined on the command line, e.g.:


Yes, thanks, I already said I find your proposition to use a DEFINE_PROP_CPUS390ENTITLEMENT good and will use it.



diff --git a/include/hw/qdev-properties-system.h b/include/hw/qdev-properties-system.h
index 0ac327ae60..41a605c5a7 100644
--- a/include/hw/qdev-properties-system.h
+++ b/include/hw/qdev-properties-system.h
@@ -22,6 +22,7 @@ extern const PropertyInfo qdev_prop_audiodev;
  extern const PropertyInfo qdev_prop_off_auto_pcibar;
  extern const PropertyInfo qdev_prop_pcie_link_speed;
  extern const PropertyInfo qdev_prop_pcie_link_width;
+extern const PropertyInfo qdev_prop_cpus390entitlement;
#define DEFINE_PROP_PCI_DEVFN(_n, _s, _f, _d) \
      DEFINE_PROP_SIGNED(_n, _s, _f, _d, qdev_prop_pci_devfn, int32_t)
@@ -73,5 +74,8 @@ extern const PropertyInfo qdev_prop_pcie_link_width;
  #define DEFINE_PROP_UUID_NODEFAULT(_name, _state, _field) \
      DEFINE_PROP(_name, _state, _field, qdev_prop_uuid, QemuUUID)
+#define DEFINE_PROP_CPUS390ENTITLEMENT(_n, _s, _f) \
+    DEFINE_PROP(_n, _s, _f, qdev_prop_cpus390entitlement, int)
+
#endif
diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
index 54541d2230..01308e0b94 100644
--- a/target/s390x/cpu.h
+++ b/target/s390x/cpu.h
@@ -135,7 +135,7 @@ struct CPUArchState {
      int32_t book_id;
      int32_t drawer_id;
      bool dedicated;
-    uint8_t entitlement;        /* Used only for vertical polarization */
+    int entitlement;        /* Used only for vertical polarization */


Isn't it better to use:

+    CpuS390Entitlement entitlement; /* Used only for vertical polarization */


      uint64_t cpuid;
  #endif
diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-properties-system.c
index d42493f630..db5c3d4fe6 100644
--- a/hw/core/qdev-properties-system.c
+++ b/hw/core/qdev-properties-system.c
@@ -1143,3 +1143,14 @@ const PropertyInfo qdev_prop_uuid = {
      .set   = set_uuid,
      .set_default_value = set_default_uuid_auto,
  };
+
+/* --- s390x cpu topology entitlement --- */
+
+QEMU_BUILD_BUG_ON(sizeof(CpuS390Entitlement) != sizeof(int));
+
+const PropertyInfo qdev_prop_cpus390entitlement = {
+    .name = "CpuS390Entitlement",
+    .enum_table = &CpuS390Entitlement_lookup,
+    .get   = qdev_propinfo_get_enum,
+    .set   = qdev_propinfo_set_enum,
+};
diff --git a/hw/s390x/cpu-topology.c b/hw/s390x/cpu-topology.c
index b8a292340c..1b3f5c61ae 100644
--- a/hw/s390x/cpu-topology.c
+++ b/hw/s390x/cpu-topology.c
@@ -199,8 +199,7 @@ static void s390_topology_cpu_default(S390CPU *cpu, Error **errp)
       * is not dedicated.
       * A dedicated CPU always receives a high entitlement.
       */
-    if (env->entitlement >= S390_CPU_ENTITLEMENT__MAX ||
-        env->entitlement == S390_CPU_ENTITLEMENT_HORIZONTAL) {
+    if (env->entitlement < 0) {


Here we can have:

+    if (env->entitlement == S390_CPU_ENTITLEMENT_AUTO) {
...

          if (env->dedicated) {
              env->entitlement = S390_CPU_ENTITLEMENT_HIGH;
          } else {
diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
index 57165fa3a0..dea50a3e06 100644
--- a/target/s390x/cpu.c
+++ b/target/s390x/cpu.c
@@ -31,6 +31,7 @@
  #include "qapi/qapi-types-machine.h"
  #include "sysemu/hw_accel.h"
  #include "hw/qdev-properties.h"
+#include "hw/qdev-properties-system.h"
  #include "fpu/softfloat-helpers.h"
  #include "disas/capstone.h"
  #include "sysemu/tcg.h"
@@ -248,6 +249,7 @@ static void s390_cpu_initfn(Object *obj)
      cs->exception_index = EXCP_HLT;
#if !defined(CONFIG_USER_ONLY)
+    cpu->env.entitlement = -1;


Then we do not need this initialization if here under we define DEFINE_PROP_CPUS390ENTITLEMENT differently


      s390_cpu_init_sysemu(obj);
  #endif
  }
@@ -264,8 +266,7 @@ static Property s390x_cpu_properties[] = {
      DEFINE_PROP_INT32("book-id", S390CPU, env.book_id, -1),
      DEFINE_PROP_INT32("drawer-id", S390CPU, env.drawer_id, -1),
      DEFINE_PROP_BOOL("dedicated", S390CPU, env.dedicated, false),
-    DEFINE_PROP_UINT8("entitlement", S390CPU, env.entitlement,
-                      S390_CPU_ENTITLEMENT__MAX),
+    DEFINE_PROP_CPUS390ENTITLEMENT("entitlement", S390CPU, env.entitlement),


+    DEFINE_PROP_CPUS390ENTITLEMENT("entitlement", S390CPU, env.entitlement,
                                   S390_CPU_ENTITLEMENT_AUTO),

  #endif
      DEFINE_PROP_END_OF_LIST()
  };

There are other ways to achieve the same, you could also
implement get, set and set_default_value so that there is an additional
"auto"/"uninitialized" value that is not in the enum.
If you insist on having an additional state in the enum, name it "auto".

Yes, I think it is a better name.





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux