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)

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 <imammedo@redhat.com>
---
 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
+various pitfalls with regards to live migration. Use a newer machine type
+instead.
+
 Nios II ``10m50-ghrd`` and ``nios2-generic-nommu`` machines (since 8.2)
 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
 
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 18ba076609..96f72384dd 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -921,6 +921,7 @@ static void isapc_machine_options(MachineClass *m)
     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);
+    m->deprecation_reason = "old and unattended - use a newer version instead";
 }
 
 DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
-- 
2.43.0
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On 26/03/2024 12: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)
> 
> 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.

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'd really hate to see isapc disappear as there are a number of people from the retro 
crowd (such as myself) who fire up QEMU/KVM on various historical images, and whilst 
there are alternatives, there isn't really anything that touches QEMU performance-wise.

This leads into the question as to how QEMU should handle less recent machines: I 
appreciate that from an enterprise perspective there is little interest, but there 
are plenty of hobbyists and historians who are.

 From my personal experience with SPARC/macppc machines I accept that they are not 
first-class citizens, and so my approach here is that I don't mind if patches break 
migration or command-line compatibility as long as I can still fire up the VM. 
Regressions do occur, but fortunately they don't tend to occur that often.

I can see how there is a lot of legacy cruft around handling legacy command line 
options that could be improved by removing isapc, and I think that a lot of this is 
around preserving historical behaviour.

How about splitting the isapc machine out of the generic PC init so that it can be 
used going forward with less command-line/migration compatibility guarantees, but 
also won't prevent subsequent tidy-ups/changes to the main PC machines going forward?

> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> ---
>   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
> +various pitfalls with regards to live migration. Use a newer machine type
> +instead.
> +
>   Nios II ``10m50-ghrd`` and ``nios2-generic-nommu`` machines (since 8.2)
>   '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>   
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 18ba076609..96f72384dd 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -921,6 +921,7 @@ static void isapc_machine_options(MachineClass *m)
>       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);
> +    m->deprecation_reason = "old and unattended - use a newer version instead";
>   }
>   
>   DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,


ATB,

Mark.

On Tue, Mar 26, 2024 at 01:30:48PM +0000, 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-leave@lists.libvirt.org

On 27/03/2024 07:09, Gerd Hoffmann wrote:

> On Tue, Mar 26, 2024 at 01:30:48PM +0000, 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.


ATB,

Mark.
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

Am 28. März 2024 14:09:52 UTC schrieb Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>:
>On 27/03/2024 07:09, Gerd Hoffmann wrote:
>
>> On Tue, Mar 26, 2024 at 01:30:48PM +0000, 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.
>
>

On Fri, Mar 29, 2024 at 10:19:09AM +0000, Bernhard Beschow wrote:
> 
> 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.

SeaBIOS will simply not use SMM in that case.

> 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?

Well, SMM support isn't that important I think.  It was introduced to
make switches to 32-bit mode more robust.  Entering SMM mode stores the
*complete* x86 processor state (which is impossible to do in other
ways), so with SMM it's possible to switch back into whatever state the
processor has been before entering 32-bit mode.

Some storage drivers (virtio, ahci) switch into 32-bit mode so they can
reach the mmio registers they need.  Some storage drivers (ide) don't,
in that case SMM doesn't change anything.

I'm not aware of any problems actually fixed by adding SMM support in
seabios.  I suspect the guest OS-es new enough to support ahci or virtio
are also new enough to not not call BIOS interfaces from non-standard
processor modes.

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

On Tue, 26 Mar 2024 13:30:48 +0000
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:

> On 26/03/2024 12: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)
> > 
> > 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.  
> 
> 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'd really hate to see isapc disappear as there are a number of people from the retro 
> crowd (such as myself) who fire up QEMU/KVM on various historical images, and whilst 
> there are alternatives, there isn't really anything that touches QEMU performance-wise.
> 
> This leads into the question as to how QEMU should handle less recent machines: I 
> appreciate that from an enterprise perspective there is little interest, but there 
> are plenty of hobbyists and historians who are.

I'm not looking at it from enterprise point of view, but rather from
developers/maintainers side.

>  From my personal experience with SPARC/macppc machines I accept that they are not 
> first-class citizens, and so my approach here is that I don't mind if patches break 
> migration or command-line compatibility as long as I can still fire up the VM. 
> Regressions do occur, but fortunately they don't tend to occur that often.
> 
> I can see how there is a lot of legacy cruft around handling legacy command line 
> options that could be improved by removing isapc, and I think that a lot of this is 
> around preserving historical behaviour.
> 
> How about splitting the isapc machine out of the generic PC init so that it can be 
> used going forward with less command-line/migration compatibility guarantees, but 
> also won't prevent subsequent tidy-ups/changes to the main PC machines going forward?

it's not only command line, it polluting code all over pc machine
(the recent example, I've touched smbios, where we have legacy mode
only for ISAPC (since 2.0 machine has been deprecated/removed)).

Yep, it should be possible to extract ISA machine at cost of some
duplication and let it slowly continue decay. But it's thanks-less
task and shared code would still remian the issue.

Old QEMU can be used for testing at the cost of few minutes to
create container without much hassle, see my other reply to Philippe.
 
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > ---
> >   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
> > +various pitfalls with regards to live migration. Use a newer machine type
> > +instead.
> > +
> >   Nios II ``10m50-ghrd`` and ``nios2-generic-nommu`` machines (since 8.2)
> >   '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> >   
> > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > index 18ba076609..96f72384dd 100644
> > --- a/hw/i386/pc_piix.c
> > +++ b/hw/i386/pc_piix.c
> > @@ -921,6 +921,7 @@ static void isapc_machine_options(MachineClass *m)
> >       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);
> > +    m->deprecation_reason = "old and unattended - use a newer version instead";
> >   }
> >   
> >   DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,  
> 
> 
> ATB,
> 
> Mark.
> 
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

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)
> 
> 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 <imammedo@redhat.com>
> ---
>   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-leave@lists.libvirt.org

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.

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 <imammedo@redhat.com>
>> ---
>>   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-leave@lists.libvirt.org

Am 26. März 2024 13:29:58 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>:
>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 <imammedo@redhat.com>
>>> ---
>>>   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-leave@lists.libvirt.org

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-leave@lists.libvirt.org

On Tue, 26 Mar 2024 14:29:58 +0100
Philippe Mathieu-Daudé <philmd@linaro.org> 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.
]

However I look at it, isapc is burden at this point 
and it gets into a way of evolving.

[downstream hat]
while both of you do a wonderful job of separating some parts
of the mess we have, it's a lot of churn which is not ideal when it
comes to backporting patches.

[emotional hat]
Nowadays with modern containers tooling it's very easy to
spawn old qemu environment to play with removed machines/features.
quick few minutes example that lets me run isapc on old ubuntu
without need to read how to build containers in 100 different ways:

 toolbox create --distro ubuntu --release 22.04
 toolbox enter ubuntu-toolbox-22.04
 toolbox enter ubuntu-toolbox-22.04
[user@toolbox ~]$ sudo apt update
[user@toolbox ~]$ sudo apt install qemu-system-x86
[user@toolbox ~]$ qemu-system-i386 -M isapc -vnc :0 my_toy.qcow2


PS:
I haven't had high hopes of this getting accepted,
but I had to try.
Though recent trend was that upstream
QEMU were deprecating/dropping old machines/devices
(even ones that kernel folks were using for testing)
and it hasn't caused the end of universe (old qemu(s)
sill exists and can be used for those cases). 

> 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 <imammedo@redhat.com>
> >> ---
> >>   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-leave@lists.libvirt.org

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é <philmd@linaro.org> 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 :|

On Wed, 27 Mar 2024 10:49:43 +0000
Daniel P. Berrangé <berrange@redhat.com> 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é <philmd@linaro.org> 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-leave@lists.libvirt.org

Il mer 27 mar 2024, 14:09 Igor Mammedov <imammedo@redhat.com> 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-leave@lists.libvirt.org

On 27/3/24 14:09, Igor Mammedov wrote:
> On Wed, 27 Mar 2024 10:49:43 +0000
> Daniel P. Berrangé <berrange@redhat.com> 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é <philmd@linaro.org> 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
> 

On Wed, Mar 27, 2024 at 02:09:17PM +0100, Igor Mammedov wrote:
> On Wed, 27 Mar 2024 10:49:43 +0000
> Daniel P. Berrangé <berrange@redhat.com> 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é <philmd@linaro.org> 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 :|

On Wed, 27 Mar 2024 at 13:23, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Wed, Mar 27, 2024 at 02:09:17PM +0100, Igor Mammedov wrote:
> > On Wed, 27 Mar 2024 10:49:43 +0000
> > Daniel P. Berrangé <berrange@redhat.com> 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-leave@lists.libvirt.org

On Wed, Mar 27, 2024 at 01:27:58PM +0000, Peter Maydell wrote:
> On Wed, 27 Mar 2024 at 13:23, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Wed, Mar 27, 2024 at 02:09:17PM +0100, Igor Mammedov wrote:
> > > On Wed, 27 Mar 2024 10:49:43 +0000
> > > Daniel P. Berrangé <berrange@redhat.com> 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 :|

On 27/03/2024 14.09, Igor Mammedov wrote:
> On Wed, 27 Mar 2024 10:49:43 +0000
> Daniel P. Berrangé <berrange@redhat.com> 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é <philmd@linaro.org> 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-leave@lists.libvirt.org

On 26/03/2024 14.29, 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.

+1

See also:

https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg01367.html

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

On 26/3/24 14:37, Thomas Huth wrote:
> On 26/03/2024 14.29, 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.
> 
> +1

Rough plan is to extract 'isapc' machine from PCMachineClass,
having the latter becoming smth like PcPciMachineClass, on
top of:
https://lore.kernel.org/qemu-devel/20240305134221.30924-1-philmd@linaro.org/

> See also:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg01367.html

lol I didn't remember I posted a similar patch =)
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

> On 26 Mar 2024, at 18:21, Igor Mammedov <imammedo@redhat.com> 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)
> 
> 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 <imammedo@redhat.com>

Reviewed-by: Ani Sinha <anisinha@redhat.com>

> ---
> 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
> +various pitfalls with regards to live migration. Use a newer machine type
> +instead.
> +
> Nios II ``10m50-ghrd`` and ``nios2-generic-nommu`` machines (since 8.2)
> '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 18ba076609..96f72384dd 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -921,6 +921,7 @@ static void isapc_machine_options(MachineClass *m)
>     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);
> +    m->deprecation_reason = "old and unattended - use a newer version instead";
> }
> 
> DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
> -- 
> 2.43.0
> _______________________________________________
> Devel mailing list -- devel@lists.libvirt.org
> To unsubscribe send an email to devel-leave@lists.libvirt.org