Re: [PATCH 4/5] hw/char/serial-isa.c: declare IRQ as shared in ACPI IRQ descriptor

[Igor Mammedov <imammedo@redhat.com>]

On Mon, 9 Mar 2026 12:24:47 +0000
Mark Cave-Ayland <mark.caveayland@nutanix.com> wrote:

> On 05/03/2026 12:49, Igor Mammedov wrote:
> 
> > On Wed, 4 Mar 2026 14:36:14 +0000
> > Mark Cave-Ayland <mark.caveayland@nutanix.com> wrote:
> >   
> >> On 04/03/2026 11:22, Igor Mammedov wrote:
> >>  
> >>> On Fri, 27 Feb 2026 13:44:58 +0000
> >>> Mark Cave-Ayland <mark.caveayland@nutanix.com> wrote:
> >>>      
> >>>>   From Windows 8.1 onwards ISA serial IRQs cannot be shared when ACPI Revision
> >>>> 5.0 is used in the FACP table. The reason for this is that if a 2-byte IRQ
> >>>> Descriptor is used then the interrupt is considered to be high true, edge
> >>>> sensitive, non-shareable. Since legacy serial ports COM1/3 and COM2/4 share
> >>>> an IRQ then if more than 2 serial ports are added, Windows indicates a
> >>>> conflict in Device Manager and these combinations cannot be used together.
> >>>>
> >>>> Add a new 3-byte IRQ Descriptor to the _CRS resource indicating that the
> >>>> ISA serial IRQ is low true, edge sensitive and shareable, along with a
> >>>> corresponding _PRS resource so that the legacy serial ports also appear
> >>>> at a fixed address. This enables all 4 legacy serial ports to be used in
> >>>> Windows without conflict.  
> >>>
> >>> What happens if we just replace aml_irq_no_flags() with aml_irq()
> >>> (without compat knob and _PRS)
> >>>
> >>> wrt _PRS could you elaborate some more why it's needed and what happens
> >>> if it doesn't exists?  
> >>
> >> Good question. I based the implementation on the technote from Microchip
> >> at https://urldefense.proofpoint.com/v2/url?u=https-3A__ww1.microchip.com_downloads_en_DeviceDoc_00001879A.pdf&d=DwICAg&c=s883GpUCOChKOHiocYtGcg&r=c23RpsaH4D2MKyD3EPJTDa0BAxz6tV8aUJqVSoytEiY&m=Nx9ld5Tg6QCayccyKhC9WQbm1DwiJT2Ja3jlwtlv8RkPFaZcU_oTHCkJZetgQLfd&s=k-ubK6tfBDM7A3BN_S3lNy3s-SJGR0fU9O5oj-GWF3A&e=  and
> >> found that it worked fine here on Windows 11.
> >>
> >> My concern from deviating from the document would be that any changes
> >> would work fine on Windows 11, but then fail on older versions of Windows.
> >>
> >> I can try and locate a copy of Windows 8.1 internally if you still think
> >> that is worth pursuing?  
> > 
> > with _CRS present, I don't think we need _PRS especially in absence of _SRS
> > and means to actually changes used IRQs/IO.
> > 
> > What I'd like to avoid is adding not needed code and compat logic
> > if it's possible.
> > The later unfortunately achievable only by tedious testing of
> > the change with older Windows versions (the older it is,
> > the more loose spec interperetation).  
> 
> I've done some more experiments with both Windows 8.1 and Windows 11, 
> and I can confirm that the _PRS isn't needed for Device Manager to 
> detect and configure the serial ports for both OSs.
> 
> However it seems that indicating a shared interrupt with aml_irq() *IS* 
> required for Device Manager to detect all 4 serial ports without conflict.
> 
> I think it would be fine to unconditionally replace aml_irq_no_flags() 
> with aml_irq() in this case, however since the ACPI tables visible to 
> the guest OS will have changed, wouldn't this still require a machine 
> compatibility property? Or do we not care because Windows will almost 
> certainly insist on a reboot for changes to legacy hardware regardless.

usually we do not do compat for ACPItables changes,
unless it introduces breaking change.
drawback of such approach is that sometimes we have to fix it afterwards
in stable when an issue is found.
But on positive side we won't drown out in compat kobs.

considering it is not default config and was broken before,
fixing it without compat knob should be fine.
 
> 
> ATB,
> 
> Mark.
>