qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

hw/i386/q35: Where go LPC irqs?


From: Philippe Mathieu-Daudé
Subject: hw/i386/q35: Where go LPC irqs?
Date: Sat, 7 Nov 2020 15:46:52 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1

Hi, I am confuse with the LPC/GSI code.

In pc_q35_init() we connect the LPC outputs to
GSI input:

116 static void pc_q35_init(MachineState *machine)
117 {
...
240     /* irq lines */
241     gsi_state = pc_gsi_create(&x86ms->gsi, pcmc->pci_enabled);
242
243     ich9_lpc = ICH9_LPC_DEVICE(lpc);
244     lpc_dev = DEVICE(lpc);
245     for (i = 0; i < GSI_NUM_PINS; i++) {
246         qdev_connect_gpio_out_named(lpc_dev, ICH9_GPIO_GSI, i,
x86ms->gsi[i]);
247     }
...
268     /* init basic PC hardware */
269     pc_basic_device_init(pcms, isa_bus, x86ms->gsi, &rtc_state,
!mc->no_floppy,
270                          0xff0104);

But then we call pc_basic_device_init() which overwrite
the GSI inputs with HPET outputs:

1118 void pc_basic_device_init(struct PCMachineState *pcms,
1119                           ISABus *isa_bus, qemu_irq *gsi,
1120                           ISADevice **rtc_state,
1121                           bool create_fdctrl,
1122                           uint32_t hpet_irqs)
1123 {
...
1139     /*
1140      * Check if an HPET shall be created.
1141      *
1142      * Without KVM_CAP_PIT_STATE2, we cannot switch off the
in-kernel PIT
1143      * when the HPET wants to take over. Thus we have to disable
the latter.
1144      */
1145     if (pcms->hpet_enabled && (!kvm_irqchip_in_kernel() ||
1146                                kvm_has_pit_state2())) {
...
1165         for (i = 0; i < GSI_NUM_PINS; i++) {
1166             sysbus_connect_irq(SYS_BUS_DEVICE(hpet), i, gsi[i]);
1167         }

Are LPC IRQ still delivered?

Peter commented here:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg758178.html

"Connecting two qemu_irqs outputs directly
to the same input is not valid as it produces subtly wrong behaviour
(for instance if both the IRQ lines are high, and then one goes
low, the PIC input will see this as a high-to-low transition
even though the second IRQ line should still be holding it high)."

Are this IRQ OR'ed to the GSI?

Thanks,

Phil.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]