Re: [pve-devel] [PATCH container] lxc start: warn in case of conflicting lxc.idmap entries
On 16/03/2023 17:09, Wolfgang Bumiller wrote: > Since it's about helping out users, even better would be to collect all > the errors together and than die() with a message containing all of > them. > And then the order doesn't matter again ;-) Agree. :) So I'll prepare a v2 that * is based on the sorting approach you suggested * reports all errors to the user (hopefully without being too verbose) * and probably removes the weird "<100 entries" limitation ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu] add patch fixing ACPI CPU hotplug issue with TCG
Required for the debian/edk2-vars-generator.py script in the
pve-edk2-firmware repository when building the edk2-stable202302
release. Without this patch, the QEMU process spawned by the script
would hang indefinietly.
Signed-off-by: Fiona Ebner
---
I'll be thinking twice about not picking up TCG-only stable fixes from
now on :/
...uest-visible-maximum-access-size-to-.patch | 166 ++
debian/patches/series | 1 +
2 files changed, 167 insertions(+)
create mode 100644
debian/patches/extra/0023-acpi-cpuhp-fix-guest-visible-maximum-access-size-to-.patch
diff --git
a/debian/patches/extra/0023-acpi-cpuhp-fix-guest-visible-maximum-access-size-to-.patch
b/debian/patches/extra/0023-acpi-cpuhp-fix-guest-visible-maximum-access-size-to-.patch
new file mode 100644
index 000..345fc4e
--- /dev/null
+++
b/debian/patches/extra/0023-acpi-cpuhp-fix-guest-visible-maximum-access-size-to-.patch
@@ -0,0 +1,166 @@
+From Mon Sep 17 00:00:00 2001
+From: Laszlo Ersek
+Date: Thu, 5 Jan 2023 17:18:04 +0100
+Subject: [PATCH] acpi: cpuhp: fix guest-visible maximum access size to the
+ legacy reg block
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The modern ACPI CPU hotplug interface was introduced in the following
+series (aa1dd39ca307..679dd1a957df), released in v2.7.0:
+
+ 1 abd49bc2ed2f docs: update ACPI CPU hotplug spec with new protocol
+ 2 16bcab97eb9f pc: piix4/ich9: add 'cpu-hotplug-legacy' property
+ 3 5e1b5d93887b acpi: cpuhp: add CPU devices AML with _STA method
+ 4 ac35f13ba8f8 pc: acpi: introduce AcpiDeviceIfClass.madt_cpu hook
+ 5 d2238cb6781d acpi: cpuhp: implement hot-add parts of CPU hotplug
+ interface
+ 6 8872c25a26cc acpi: cpuhp: implement hot-remove parts of CPU hotplug
+ interface
+ 7 76623d00ae57 acpi: cpuhp: add cpu._OST handling
+ 8 679dd1a957df pc: use new CPU hotplug interface since 2.7 machine type
+
+Before patch#1, "docs/specs/acpi_cpu_hotplug.txt" only specified 1-byte
+accesses for the hotplug register block. Patch#1 preserved the same
+restriction for the legacy register block, but:
+
+- it specified DWORD accesses for some of the modern registers,
+
+- in particular, the switch from the legacy block to the modern block
+ would require a DWORD write to the *legacy* block.
+
+The latter functionality was then implemented in cpu_status_write()
+[hw/acpi/cpu_hotplug.c], in patch#8.
+
+Unfortunately, all DWORD accesses depended on a dormant bug: the one
+introduced in earlier commit a014ed07bd5a ("memory: accept mismatching
+sizes in memory_region_access_valid", 2013-05-29); first released in
+v1.6.0. Due to commit a014ed07bd5a, the DWORD accesses to the *legacy*
+CPU hotplug register block would work in spite of the above series *not*
+relaxing "valid.max_access_size = 1" in "hw/acpi/cpu_hotplug.c":
+
+> static const MemoryRegionOps AcpiCpuHotplug_ops = {
+> .read = cpu_status_read,
+> .write = cpu_status_write,
+> .endianness = DEVICE_LITTLE_ENDIAN,
+> .valid = {
+> .min_access_size = 1,
+> .max_access_size = 1,
+> },
+> };
+
+Later, in commits e6d0c3ce6895 ("acpi: cpuhp: introduce 'Command data 2'
+field", 2020-01-22) and ae340aa3d256 ("acpi: cpuhp: spec: add typical
+usecases", 2020-01-22), first released in v5.0.0, the modern CPU hotplug
+interface (including the documentation) was extended with another DWORD
+*read* access, namely to the "Command data 2" register, which would be
+important for the guest to confirm whether it managed to switch the
+register block from legacy to modern.
+
+This functionality too silently depended on the bug from commit
+a014ed07bd5a.
+
+In commit 5d971f9e6725 ('memory: Revert "memory: accept mismatching sizes
+in memory_region_access_valid"', 2020-06-26), first released in v5.1.0,
+the bug from commit a014ed07bd5a was fixed (the commit was reverted).
+That swiftly exposed the bug in "AcpiCpuHotplug_ops", still present from
+the v2.7.0 series quoted at the top -- namely the fact that
+"valid.max_access_size = 1" didn't match what the guest was supposed to
+do, according to the spec ("docs/specs/acpi_cpu_hotplug.txt").
+
+The symptom is that the "modern interface negotiation protocol"
+described in commit ae340aa3d256:
+
+> + Use following steps to detect and enable modern CPU hotplug interface:
+> +1. Store 0x0 to the 'CPU selector' register,
+> + attempting to switch to modern mode
+> +2. Store 0x0 to the 'CPU selector' register,
+> + to ensure valid selector value
+> +3. Store 0x0 to the 'Command field' register,
+> +4. Read the 'Command data 2' register.
+> + If read value is 0x0, the modern interface is enabled.
+> + Otherwise legacy or no CPU hotplug interface available
+
+falls apart for the guest: steps 1 and 2 are lost, because they are DWORD
+writes; so
[pve-devel] applied: [PATCH v3 manager 2/2] ui: backup: replication: replace non-clickable checkbox with icons
On 26/01/2023 11:47, Lukas Wagner wrote: > From a usability view, having a checkbox that is not clickable is pretty > misleading, especially if the visual style is exactly the same as in > other places in the UI where the checkbox is functional. > > Signed-off-by: Lukas Wagner > --- > www/manager6/dc/Backup.js| 6 ++ > www/manager6/grid/Replication.js | 7 --- > 2 files changed, 6 insertions(+), 7 deletions(-) > > applied, but expanded the calls to renderEnabledIcon for now to avoid doing an immediate widget-toolkit bump + debian/control version dependency bump in manager, thanks! ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH v3 widget-toolkit 1/2] repo view: replace non-clickable checkbox with icons
On 26/01/2023 11:47, Lukas Wagner wrote: > From a usability view, having a checkbox that is not clickable is pretty > misleading, especially if the visual style is exactly the same as in > other places in the UI where the checkbox is functional. > > Signed-off-by: Lukas Wagner > --- > src/Utils.js| 2 ++ > src/node/APTRepositories.js | 6 ++ > 2 files changed, 4 insertions(+), 4 deletions(-) > > applied, thanks! ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: Re: [PATCH qemu] add patch fixing ACPI CPU hotplug issue with TCG
On 17/03/2023 11:39, Fiona Ebner wrote: > Required for the debian/edk2-vars-generator.py script in the > pve-edk2-firmware repository when building the edk2-stable202302 > release. Without this patch, the QEMU process spawned by the script > would hang indefinietly. spotted above s/indefinietly/indefinitely/ to late to fix it up, argh > > Signed-off-by: Fiona Ebner > --- > > I'll be thinking twice about not picking up TCG-only stable fixes from > now on :/ hehe > > ...uest-visible-maximum-access-size-to-.patch | 166 ++ > debian/patches/series | 1 + > 2 files changed, 167 insertions(+) > create mode 100644 > debian/patches/extra/0023-acpi-cpuhp-fix-guest-visible-maximum-access-size-to-.patch > > applied, thanks! ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu] cherry-pick TCG-related stable fixes for 7.2
When turning off the "KVM hardware virtualization" checkbox in Proxmox
VE, the TCG accelerator is used, so these fixes are relevant then.
The first patch is included to allow cherry-picking the others without
changes.
Reported-by: Thomas Lamprecht
Signed-off-by: Fiona Ebner
---
...Introduce-and-use-reg_t-consistently.patch | 286 ++
...25-target-i386-Fix-BEXTR-instruction.patch | 97 ++
...i386-Fix-C-flag-for-BLSI-BLSMSK-BLSR.patch | 47 +++
...arget-i386-fix-ADOX-followed-by-ADCX.patch | 192
...028-target-i386-Fix-BZHI-instruction.patch | 64
debian/patches/series | 5 +
6 files changed, 691 insertions(+)
create mode 100644
debian/patches/extra/0024-tests-tcg-i386-Introduce-and-use-reg_t-consistently.patch
create mode 100644
debian/patches/extra/0025-target-i386-Fix-BEXTR-instruction.patch
create mode 100644
debian/patches/extra/0026-target-i386-Fix-C-flag-for-BLSI-BLSMSK-BLSR.patch
create mode 100644
debian/patches/extra/0027-target-i386-fix-ADOX-followed-by-ADCX.patch
create mode 100644
debian/patches/extra/0028-target-i386-Fix-BZHI-instruction.patch
diff --git
a/debian/patches/extra/0024-tests-tcg-i386-Introduce-and-use-reg_t-consistently.patch
b/debian/patches/extra/0024-tests-tcg-i386-Introduce-and-use-reg_t-consistently.patch
new file mode 100644
index 000..a4bcb71
--- /dev/null
+++
b/debian/patches/extra/0024-tests-tcg-i386-Introduce-and-use-reg_t-consistently.patch
@@ -0,0 +1,286 @@
+From Mon Sep 17 00:00:00 2001
+From: Richard Henderson
+Date: Sat, 14 Jan 2023 13:05:41 -1000
+Subject: [PATCH] tests/tcg/i386: Introduce and use reg_t consistently
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Define reg_t based on the actual register width.
+Define the inlines using that type. This will allow
+input registers to 32-bit insns to be set to 64-bit
+values on x86-64, which allows testing various edge cases.
+
+Signed-off-by: Richard Henderson
+Reviewed-by: Philippe Mathieu-Daudé
+Message-Id: <20230114230542.3116013-2-richard.hender...@linaro.org>
+Signed-off-by: Paolo Bonzini
+(cherry-picked from commit 5d62d6649cd367b5b4a3676e7514d2f9ca86cb03)
+Signed-off-by: Fiona Ebner
+---
+ tests/tcg/i386/test-i386-bmi2.c | 182
+ 1 file changed, 93 insertions(+), 89 deletions(-)
+
+diff --git a/tests/tcg/i386/test-i386-bmi2.c b/tests/tcg/i386/test-i386-bmi2.c
+index 5fadf47510..3c3ef85513 100644
+--- a/tests/tcg/i386/test-i386-bmi2.c
b/tests/tcg/i386/test-i386-bmi2.c
+@@ -3,34 +3,40 @@
+ #include
+ #include
+
++#ifdef __x86_64
++typedef uint64_t reg_t;
++#else
++typedef uint32_t reg_t;
++#endif
++
+ #define insn1q(name, arg0)
\
+-static inline uint64_t name##q(uint64_t arg0)
\
++static inline reg_t name##q(reg_t arg0)
\
+ {
\
+-uint64_t result64;
\
++reg_t result64;
\
+ asm volatile (#name "q %1, %0" : "=r"(result64) : "rm"(arg0));
\
+ return result64;
\
+ }
+
+ #define insn1l(name, arg0)
\
+-static inline uint32_t name##l(uint32_t arg0)
\
++static inline reg_t name##l(reg_t arg0)
\
+ {
\
+-uint32_t result32;
\
++reg_t result32;
\
+ asm volatile (#name "l %k1, %k0" : "=r"(result32) : "rm"(arg0));
\
+ return result32;
\
+ }
+
+ #define insn2q(name, arg0, c0, arg1, c1)
\
+-static inline uint64_t name##q(uint64_t arg0, uint64_t arg1)
\
++static inline reg_t name##q(reg_t arg0, reg_t arg1)
\
+ {
\
+-uint64_t result64;
\
++reg_t result64;
\
+ asm volatile (#name "q %2, %1, %0" : "=r"(result64) : c0(arg0),
c1(arg1)); \
+ return result64;
\
+ }
+
+ #define insn2l(name, arg0, c0, arg1, c1)
Re: [pve-devel] [RFC OPTIONAL pve-cluster 1/1] add arcsize to rrd
On 15.03.2023 12:51, Matthias Heiserer wrote:
On 15.03.2023 12:10, Dominik Csapak wrote:
hi not sure we would want to do it this way, since
this will only work for the node where the new pve-cluster
is installed, the other nodes will not be able to update their
local database with the info from the new nodes
AFAIR, the way we dealt with rrd updates in the past is
that we introduced a new db (like pve2.3-vm) which is also
not available on older nodes, but it does not error out, since
it won't match and we don't try to update it
I thought I had tested that and it would just discard the value, instead
of erroring. but I'll check again, not sure rn
tested it, it indeed does not work, but no error is being logged
i guess a separate db is the next best option
On 1/25/23 12:29, Matthias Heiserer wrote:
To modify the existing rrd store, rrdtool is required
Signed-off-by: Matthias Heiserer
---
data/src/status.c | 1 +
debian/control | 1 +
debian/pve-cluster.postinst | 6 ++
3 files changed, 8 insertions(+)
create mode 100644 debian/pve-cluster.postinst
diff --git a/data/src/status.c b/data/src/status.c
index 5e1e841..9290141 100644
--- a/data/src/status.c
+++ b/data/src/status.c
@@ -1130,6 +1130,7 @@ static const char *rrd_def_node[] = {
"DS:rootused:GAUGE:120:0:U",
"DS:netin:DERIVE:120:0:U",
"DS:netout:DERIVE:120:0:U",
+ "DS:arcsize:GAUGE:120:0:U",
"RRA:AVERAGE:0.5:1:70", // 1 min avg - one hour
"RRA:AVERAGE:0.5:30:70", // 30 min avg - one day
diff --git a/debian/control b/debian/control
index 2d5a01f..22d96c2 100644
--- a/debian/control
+++ b/debian/control
@@ -37,6 +37,7 @@ Depends: corosync (>= 2.3.4-1),
libsqlite3-0,
sqlite3,
systemd,
+ rrdtool,
${misc:Depends},
${perl:Depends},
${shlibs:Depends},
diff --git a/debian/pve-cluster.postinst b/debian/pve-cluster.postinst
new file mode 100644
index 000..cf475cc
--- /dev/null
+++ b/debian/pve-cluster.postinst
@@ -0,0 +1,6 @@
+#!/bin/bash
+
+RRD_DB="/var/lib/rrdcached/db/pve2-node/`hostname`"
+if [ -f $RRD_DB ] && [ `rrdtool info $RRD_DB | grep -q arcsize` ]; then
+ rrdtool tune $RRD_DB 'DS:arcsize:GAUGE:120:0:U'
+fi
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH v5 qemu-server 01/12] memory: rename qemu_dimm_list to qemu_memdevices_list
Am 24.02.23 um 13:09 schrieb Alexandre Derumier:
> current qemu_dimm_list can return any kind of memory devices.
>
> make it more generic, with an optionnal type device
>
> Signed-off-by: Alexandre Derumier
> ---
> PVE/QemuServer/Memory.pm | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/PVE/QemuServer/Memory.pm b/PVE/QemuServer/Memory.pm
> index 8984821..7ad8fcb 100644
> --- a/PVE/QemuServer/Memory.pm
> +++ b/PVE/QemuServer/Memory.pm
> @@ -240,7 +240,7 @@ sub qemu_memory_hotplug {
> while (1) {
> eval { PVE::QemuServer::qemu_devicedel($vmid, $name) };
> sleep 3;
> - my $dimm_list = qemu_dimm_list($vmid);
> + my $dimm_list = qemu_memdevices_list($vmid, 'dimm');
> last if !$dimm_list->{$name};
> raise_param_exc({ $name => "error unplug memory module" })
> if $retry > 5;
> $retry++;
> @@ -255,14 +255,14 @@ sub qemu_memory_hotplug {
> }
> }
>
> -sub qemu_dimm_list {
> -my ($vmid) = @_;
> +sub qemu_memdevices_list {
> +my ($vmid, $type) = @_;
>
> my $dimmarray = mon_cmd($vmid, "query-memory-devices");
> my $dimms = {};
>
> foreach my $dimm (@$dimmarray) {
> -
> +next if $type && $dimm->{data}->{id} !~ /^$type(\d+)$/;
> $dimms->{$dimm->{data}->{id}}->{id} = $dimm->{data}->{id};
> $dimms->{$dimm->{data}->{id}}->{node} = $dimm->{data}->{node};
> $dimms->{$dimm->{data}->{id}}->{addr} = $dimm->{data}->{addr};
applied, thanks!
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH v5 qemu-server 02/12] memory: don't use foreach_reversedimm for unplug
Am 24.02.23 um 13:09 schrieb Alexandre Derumier:
> simple use dimm_list() returned by qemu
>
> Signed-off-by: Alexandre Derumier
Thanks! Applied with this follow-up:
> memory: hotplug: sort by numerical ID rather than slot when unplugging
>
> While, usually, the slot should match the ID, it's not explicitly
> guaranteed and relies on QEMU internals. Using the numerical ID is
> more future-proof and more consistent with plugging, where no slot
> information (except the maximum limit) is relied upon.
>
> Signed-off-by: Fiona Ebner
> ---
> PVE/QemuServer/Memory.pm | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/PVE/QemuServer/Memory.pm b/PVE/QemuServer/Memory.pm
> index 0f4229c5..0601dd6c 100644
> --- a/PVE/QemuServer/Memory.pm
> +++ b/PVE/QemuServer/Memory.pm
> @@ -201,7 +201,7 @@ sub qemu_memory_hotplug {
> my $dimms = qemu_memdevices_list($vmid, 'dimm');
>
> my $current_size = $memory;
> - for my $name (sort { $dimms->{$b}->{slot} <=> $dimms->{$a}->{slot} }
> keys %$dimms) {
> + for my $name (sort { ($b =~ /^dimm(\d+)$/)[0] <=> ($a =~
> /^dimm(\d+)$/)[0] } keys %$dimms) {
>
> my $dimm_size = $dimms->{$name}->{size} / 1024 / 1024;
>
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: Re: [PATCH docs v2] conf: add support for a dark mode in the documentation
On 16/03/2023 18:02, Stefan Sterz wrote: > this commit adds support for a dark theme that behaves similarly to > that one used by the api viewer. > > Signed-off-by: Stefan Sterz > --- > asciidoc/pve-docs.css | 168 + > asciidoc/pve-html.conf | 4 + > 2 files changed, 172 insertions(+) > create mode 100644 asciidoc/pve-docs.css > > applied, thanks! ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: Re: [PATCH qemu] cherry-pick TCG-related stable fixes for 7.2
On 17/03/2023 13:47, Fiona Ebner wrote: > When turning off the "KVM hardware virtualization" checkbox in Proxmox > VE, the TCG accelerator is used, so these fixes are relevant then. > > The first patch is included to allow cherry-picking the others without > changes. > > Reported-by: Thomas Lamprecht > Signed-off-by: Fiona Ebner > --- > ...Introduce-and-use-reg_t-consistently.patch | 286 ++ > ...25-target-i386-Fix-BEXTR-instruction.patch | 97 ++ > ...i386-Fix-C-flag-for-BLSI-BLSMSK-BLSR.patch | 47 +++ > ...arget-i386-fix-ADOX-followed-by-ADCX.patch | 192 > ...028-target-i386-Fix-BZHI-instruction.patch | 64 > debian/patches/series | 5 + > 6 files changed, 691 insertions(+) > create mode 100644 > debian/patches/extra/0024-tests-tcg-i386-Introduce-and-use-reg_t-consistently.patch > create mode 100644 > debian/patches/extra/0025-target-i386-Fix-BEXTR-instruction.patch > create mode 100644 > debian/patches/extra/0026-target-i386-Fix-C-flag-for-BLSI-BLSMSK-BLSR.patch > create mode 100644 > debian/patches/extra/0027-target-i386-fix-ADOX-followed-by-ADCX.patch > create mode 100644 > debian/patches/extra/0028-target-i386-Fix-BZHI-instruction.patch > > applied, thanks! ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] applied: [PATCH v5 qemu-server 02/12] memory: don't use foreach_reversedimm for unplug
Hi Fiona,
I don't have checked yet, but does I need to rebase the other virtio-
mem patches ?
Le vendredi 17 mars 2023 à 14:39 +0100, Fiona Ebner a écrit :
> Am 24.02.23 um 13:09 schrieb Alexandre Derumier:
> > simple use dimm_list() returned by qemu
> >
> > Signed-off-by: Alexandre Derumier
>
> Thanks! Applied with this follow-up:
>
> > memory: hotplug: sort by numerical ID rather than slot when
> > unplugging
> >
> > While, usually, the slot should match the ID, it's not
> > explicitly
> > guaranteed and relies on QEMU internals. Using the numerical ID
> > is
> > more future-proof and more consistent with plugging, where no
> > slot
> > information (except the maximum limit) is relied upon.
> >
> > Signed-off-by: Fiona Ebner
> > ---
> > PVE/QemuServer/Memory.pm | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/PVE/QemuServer/Memory.pm b/PVE/QemuServer/Memory.pm
> > index 0f4229c5..0601dd6c 100644
> > --- a/PVE/QemuServer/Memory.pm
> > +++ b/PVE/QemuServer/Memory.pm
> > @@ -201,7 +201,7 @@ sub qemu_memory_hotplug {
> > my $dimms = qemu_memdevices_list($vmid, 'dimm');
> >
> > my $current_size = $memory;
> > - for my $name (sort { $dimms->{$b}->{slot} <=> $dimms->{$a}-
> > >{slot} } keys %$dimms) {
> > + for my $name (sort { ($b =~ /^dimm(\d+)$/)[0] <=> ($a =~
> > /^dimm(\d+)$/)[0] } keys %$dimms) {
> >
> > my $dimm_size = $dimms->{$name}->{size} / 1024 / 1024;
> >
>
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
