they are masked out. I am far away from x86 APIC/LAPIC/SAPIC/WhateverAPIC, but the idea is that there is 1 or 2 IRQ lines from the interrupt controller to the processor, and a bunch of irqs from devices to the interrupt controller. those are different. Disabling you mention is disabling the fiirst. processor doesn't want to listen to PIC at this time. IRQLs are masking the second ones. that bunch of device (and software as well) irqs are prioritized inside of PIC, by masking some of them out when the other of the higher priority fires. let's say the irq from the system timer is at the higher IRQL than from UART. So when the timer irq fires, OS interrupt dispatcher masks out UART irq and others that are of the lower priority than the system timer's irq. only when interrupt dispatcher is messing around with the interrupt controller, masking out irqs, it disables CPU IRQ in order to not get invoked reentrantly, I doubt intrerrupt dispatchers could be reentrant. it's a quick time, it's not ISR, it's an interrupt dispatching routine. It calls the appropriate ISR with interrupts enabled. it's all very architecture dependent, so I might write too unclear for the x86 realm.
On the mips machine I program, interrupt controller has 64 interrupt sources, and you can easily mask each of them out as you wish, so there is no hardware/software distinction for IRQLs, it's a mechainsm for prioritizing device and software interrupts.
Of course, there is another level of irq masking - a device itself.
1) Processor could disable its listening to its irq line(s) (arm has irq and fiq). (interrupt dispatching)
2) interrupt controller has a lot of irq sources representing interrupts from devices (IRQL)
3) devices have its own distinction between what exactly caused irq inside of them as well as ability of irq masking. (ISR/DPC).