Re: [PATCH-for-9.1 v2 0/3] rdma: Remove RDMA subsystem and pvrdma device
On Thu, Mar 28, 2024 at 02:02:52PM +0100, Philippe Mathieu-Daudé wrote: > Since v1: > - split in 3 (Thomas) > - justify gluster removal Reviewed-by: Michael S. Tsirkin > Philippe Mathieu-Daudé (3): > hw/rdma: Remove pvrdma device and rdmacm-mux helper > migration: Remove RDMA protocol handling > block/gluster: Remove RDMA protocol handling > > MAINTAINERS | 17 - > docs/about/deprecated.rst |9 - > docs/about/removed-features.rst |4 + > docs/devel/migration/main.rst |6 - > docs/pvrdma.txt | 345 -- > docs/rdma.txt | 420 -- > docs/system/device-url-syntax.rst.inc |4 +- > docs/system/loongarch/virt.rst|2 +- > docs/system/qemu-block-drivers.rst.inc|1 - > meson.build | 59 - > qapi/machine.json | 17 - > qapi/migration.json | 31 +- > qapi/qapi-schema.json |1 - > qapi/rdma.json| 38 - > contrib/rdmacm-mux/rdmacm-mux.h | 61 - > hw/rdma/rdma_backend.h| 129 - > hw/rdma/rdma_backend_defs.h | 76 - > hw/rdma/rdma_rm.h | 97 - > hw/rdma/rdma_rm_defs.h| 146 - > hw/rdma/rdma_utils.h | 63 - > hw/rdma/trace.h |1 - > hw/rdma/vmw/pvrdma.h | 144 - > hw/rdma/vmw/pvrdma_dev_ring.h | 46 - > hw/rdma/vmw/pvrdma_qp_ops.h | 28 - > hw/rdma/vmw/trace.h |1 - > include/hw/rdma/rdma.h| 37 - > include/monitor/hmp.h |1 - > .../infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h | 685 --- > .../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h | 348 -- > .../standard-headers/rdma/vmw_pvrdma-abi.h| 310 -- > migration/migration-stats.h |6 +- > migration/migration.h |9 - > migration/options.h |2 - > migration/rdma.h | 69 - > block/gluster.c | 39 - > contrib/rdmacm-mux/main.c | 831 > hw/core/machine-qmp-cmds.c| 32 - > hw/rdma/rdma.c| 30 - > hw/rdma/rdma_backend.c| 1401 -- > hw/rdma/rdma_rm.c | 812 > hw/rdma/rdma_utils.c | 126 - > hw/rdma/vmw/pvrdma_cmd.c | 815 > hw/rdma/vmw/pvrdma_dev_ring.c | 141 - > hw/rdma/vmw/pvrdma_main.c | 735 --- > hw/rdma/vmw/pvrdma_qp_ops.c | 298 -- > migration/migration-stats.c |5 +- > migration/migration.c | 31 - > migration/options.c | 16 - > migration/qemu-file.c |1 - > migration/ram.c | 86 +- > migration/rdma.c | 4184 - > migration/savevm.c|2 +- > monitor/qmp-cmds.c|1 - > Kconfig.host |3 - > contrib/rdmacm-mux/meson.build|7 - > hmp-commands-info.hx | 13 - > hw/Kconfig|1 - > hw/meson.build|1 - > hw/rdma/Kconfig |3 - > hw/rdma/meson.build | 12 - > hw/rdma/trace-events | 31 - > hw/rdma/vmw/trace-events | 17 - > meson_options.txt |4 - > migration/meson.build |1 - > migration/trace-events| 68 +- > qapi/meson.build |1 - > qemu-options.hx |6 - > .../org.centos/stream/8/build-environment.yml |1 - > .../ci/org.centos/stream/8/x86_64/configure |3 - > scripts/ci/setup/build-environment.yml|4 - > scripts/coverity-scan/run-coverity-scan |2 +- > scripts/meson-buildoptions.sh |6 - > scripts/update-linux-headers.sh | 27 - > tests/lcitool/projects/qemu.yml |3 - > tests/migration/guestperf/engine.py |4 +- > 75 files changed, 20 insertions(+), 12997 deletions(-) > delete mode 100644 docs/pvrdma.txt > delete mode 100644 docs/rdma.txt > delete mode 100644 qapi/rdma.json > delete mode 100644 contrib/rdmacm-mux/rdmacm-mux.h > delete mode 100644
Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated
Am 28. März 2024 14:09:52 UTC schrieb Mark Cave-Ayland : >On 27/03/2024 07:09, Gerd Hoffmann wrote: > >> 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 ... > >Hmmm that's a fair point: I think the pc machine has a PCI-ISA bridge >included, so ISA devices can be plugged in as needed. The reason I ended up on >that configuration was because I ended up chasing down a regression, and >wanted to quickly eliminate things such as ACPI. In theory you could pass `-M acpi=off` to not instantiate the PIIX4 ACPI function, essentially turning the Frankenstein-PIIX4 SB into a PIIX3. However, this also removes SMI registers used by SeaBIOS to handle SMM setup which may create unwanted side effects. On a real PIIX3, these registers are located in the ISA function. I wonder if it made sense to implement that for greater compatibility. What do you think? Gerd, what do you think w.r.t. SeaBIOS? Best regards, Bernhard > > >ATB, > >Mark. > > ___ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: [PATCH-for-9.0 v2] hw/i386/pc: Deprecate 64-bit CPUs on ISA-only PC machine
On 28/3/24 16:39, Thomas Huth wrote:
On 28/03/2024 16.12, Mark Cave-Ayland wrote:
On 27/03/2024 16:54, 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.
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);
The logic around checking CPUID_EXT2_LM looks good to me. Slightly
curious as to whether people feel updating PCMachineClass is
necessary, or you can simply do qdev_get_machine() and use
object_dynamic_cast() to see if the machine matches
MACHINE_NAME("isapc") and warn that way?
Why don't you simply pass it as a parameter from pc_init_isa() instead?
Or do the whole check in pc_init_isa() instead?
Because the CPU isn't instantiated so we can't check the CPUID_EXT2_LM
feature :/
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: [PATCH-for-9.1 v2 2/3] migration: Remove RDMA protocol handling
Hi Zhijian,
On 29/3/24 02:53, Zhijian Li (Fujitsu) wrote:
On 28/03/2024 23:01, Peter Xu wrote:
On Thu, Mar 28, 2024 at 11:18:04AM -0300, Fabiano Rosas wrote:
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.
Remove:
- RDMA handling from migration
- dependencies on libibumad, libibverbs and librdmacm
Keep the RAM_SAVE_FLAG_HOOK definition since it might appears
in old migration streams.
Cc: Peter Xu
Cc: Li Zhijian
Acked-by: Fabiano Rosas
Signed-off-by: Philippe Mathieu-Daudé
Just to be clear, because people raised the point in the last version,
the first link in the deprecation commit links to a thread comprising
entirely of rdma migration patches. I don't see any ambiguity on whether
the deprecation was intended to include migration. There's even an ack
from Juan.
Yes I remember that's the plan.
So on the basis of not reverting the previous maintainer's decision, my
Ack stands here.
We also had pretty obvious bugs ([1], [2]) in the past that would have
been caught if we had any kind of testing for the feature, so I can't
even say this thing works currently.
@Peter Xu, @Li Zhijian, what are your thoughts on this?
Generally I definitely agree with such a removal sooner or later, as that's
how deprecation works, and even after Juan's left I'm not aware of any
other new RDMA users. Personally, I'd slightly prefer postponing it one
more release which might help a bit of our downstream maintenance, however
I assume that's not a blocker either, as I think we can also manage it.
IMHO it's more important to know whether there are still users and whether
they would still like to see it around. That's also one thing I notice that
e9a54265f533f didn't yet get acks from RDMA users that we are aware, even
if they're rare. According to [2] it could be that such user may only rely
on the release versions of QEMU when it broke things.
So I'm copying Yu too (while Zhijian is already in the loop), just in case
someone would like to stand up and speak.
I admit RDMA migration was lack of testing(unit/CI test), which led to the a few
obvious bugs being noticed too late.
However I was a bit surprised when I saw the removal of the RDMA migration. I
wasn't
aware that this feature has not been marked as deprecated(at least there is no
prompt to end-user).
IMHO it's more important to know whether there are still users and whether
they would still like to see it around.
Agree.
I didn't immediately express my opinion in V1 because I'm also consulting our
customers for this feature in the future.
Personally, I agree with Perter's idea that "I'd slightly prefer postponing it
one
more release which might help a bit of our downstream maintenance"
Do you mind posting a deprecation patch to clarify the situation?
Thanks,
Phil.
Thanks
Zhijian
Thanks,
1- https://lore.kernel.org/r/20230920090412.726725-1-lizhij...@fujitsu.com
2-
https://lore.kernel.org/r/cahecvy7hxswn4ow_kog+q+tn6f_kmeichevz1qgm-fbxbpp...@mail.gmail.com
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: [PATCH-for-9.1 v2 2/3] migration: Remove RDMA protocol handling
On 28/03/2024 23:01, Peter Xu wrote:
> On Thu, Mar 28, 2024 at 11:18:04AM -0300, Fabiano Rosas wrote:
>> 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.
>>>
>>> Remove:
>>> - RDMA handling from migration
>>> - dependencies on libibumad, libibverbs and librdmacm
>>>
>>> Keep the RAM_SAVE_FLAG_HOOK definition since it might appears
>>> in old migration streams.
>>>
>>> Cc: Peter Xu
>>> Cc: Li Zhijian
>>> Acked-by: Fabiano Rosas
>>> Signed-off-by: Philippe Mathieu-Daudé
>>
>> Just to be clear, because people raised the point in the last version,
>> the first link in the deprecation commit links to a thread comprising
>> entirely of rdma migration patches. I don't see any ambiguity on whether
>> the deprecation was intended to include migration. There's even an ack
>> from Juan.
>
> Yes I remember that's the plan.
>
>>
>> So on the basis of not reverting the previous maintainer's decision, my
>> Ack stands here.
>>
>> We also had pretty obvious bugs ([1], [2]) in the past that would have
>> been caught if we had any kind of testing for the feature, so I can't
>> even say this thing works currently.
>>
>> @Peter Xu, @Li Zhijian, what are your thoughts on this?
>
> Generally I definitely agree with such a removal sooner or later, as that's
> how deprecation works, and even after Juan's left I'm not aware of any
> other new RDMA users. Personally, I'd slightly prefer postponing it one
> more release which might help a bit of our downstream maintenance, however
> I assume that's not a blocker either, as I think we can also manage it.
>
> IMHO it's more important to know whether there are still users and whether
> they would still like to see it around. That's also one thing I notice that
> e9a54265f533f didn't yet get acks from RDMA users that we are aware, even
> if they're rare. According to [2] it could be that such user may only rely
> on the release versions of QEMU when it broke things.
>
> So I'm copying Yu too (while Zhijian is already in the loop), just in case
> someone would like to stand up and speak.
I admit RDMA migration was lack of testing(unit/CI test), which led to the a few
obvious bugs being noticed too late.
However I was a bit surprised when I saw the removal of the RDMA migration. I
wasn't
aware that this feature has not been marked as deprecated(at least there is no
prompt to end-user).
> IMHO it's more important to know whether there are still users and whether
> they would still like to see it around.
Agree.
I didn't immediately express my opinion in V1 because I'm also consulting our
customers for this feature in the future.
Personally, I agree with Perter's idea that "I'd slightly prefer postponing it
one
more release which might help a bit of our downstream maintenance"
Thanks
Zhijian
>
> Thanks,
>
>>
>> 1- https://lore.kernel.org/r/20230920090412.726725-1-lizhij...@fujitsu.com
>> 2-
>> https://lore.kernel.org/r/cahecvy7hxswn4ow_kog+q+tn6f_kmeichevz1qgm-fbxbpp...@mail.gmail.com
>>
>
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: [PATCH-for-9.1 v2 2/3] migration: Remove RDMA protocol handling
On Fri, Mar 29, 2024 at 11:28:54AM +0100, Philippe Mathieu-Daudé wrote:
> Hi Zhijian,
>
> On 29/3/24 02:53, Zhijian Li (Fujitsu) wrote:
> >
> >
> > On 28/03/2024 23:01, Peter Xu wrote:
> > > On Thu, Mar 28, 2024 at 11:18:04AM -0300, Fabiano Rosas wrote:
> > > > 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.
> > > > >
> > > > > Remove:
> > > > >- RDMA handling from migration
> > > > >- dependencies on libibumad, libibverbs and librdmacm
> > > > >
> > > > > Keep the RAM_SAVE_FLAG_HOOK definition since it might appears
> > > > > in old migration streams.
> > > > >
> > > > > Cc: Peter Xu
> > > > > Cc: Li Zhijian
> > > > > Acked-by: Fabiano Rosas
> > > > > Signed-off-by: Philippe Mathieu-Daudé
> > > >
> > > > Just to be clear, because people raised the point in the last version,
> > > > the first link in the deprecation commit links to a thread comprising
> > > > entirely of rdma migration patches. I don't see any ambiguity on whether
> > > > the deprecation was intended to include migration. There's even an ack
> > > > from Juan.
> > >
> > > Yes I remember that's the plan.
> > >
> > > >
> > > > So on the basis of not reverting the previous maintainer's decision, my
> > > > Ack stands here.
> > > >
> > > > We also had pretty obvious bugs ([1], [2]) in the past that would have
> > > > been caught if we had any kind of testing for the feature, so I can't
> > > > even say this thing works currently.
> > > >
> > > > @Peter Xu, @Li Zhijian, what are your thoughts on this?
> > >
> > > Generally I definitely agree with such a removal sooner or later, as
> > > that's
> > > how deprecation works, and even after Juan's left I'm not aware of any
> > > other new RDMA users. Personally, I'd slightly prefer postponing it one
> > > more release which might help a bit of our downstream maintenance, however
> > > I assume that's not a blocker either, as I think we can also manage it.
> > >
> > > IMHO it's more important to know whether there are still users and whether
> > > they would still like to see it around. That's also one thing I notice
> > > that
> > > e9a54265f533f didn't yet get acks from RDMA users that we are aware, even
> > > if they're rare. According to [2] it could be that such user may only rely
> > > on the release versions of QEMU when it broke things.
> > >
> > > So I'm copying Yu too (while Zhijian is already in the loop), just in case
> > > someone would like to stand up and speak.
> >
> >
> > I admit RDMA migration was lack of testing(unit/CI test), which led to the
> > a few
> > obvious bugs being noticed too late.
> > However I was a bit surprised when I saw the removal of the RDMA migration.
> > I wasn't
> > aware that this feature has not been marked as deprecated(at least there is
> > no
> > prompt to end-user).
> >
> >
> > > IMHO it's more important to know whether there are still users and whether
> > > they would still like to see it around.
> >
> > Agree.
> > I didn't immediately express my opinion in V1 because I'm also consulting
> > our
> > customers for this feature in the future.
> >
> > Personally, I agree with Perter's idea that "I'd slightly prefer postponing
> > it one
> > more release which might help a bit of our downstream maintenance"
>
> Do you mind posting a deprecation patch to clarify the situation?
The key thing the first deprecation patch missed was that it failed
to issue a warning message when RDMA migration was actually used.
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
