From: Julia Suvorova <jusual@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
Eduardo Habkost <ehabkost@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: hw/i386/q35: Where go LPC irqs?
Date: Wed, 11 Nov 2020 13:58:46 +0100 [thread overview]
Message-ID: <CAMDeoFXmT3gdh5JOh5RopzYBjTTPwrHWZbHp0vwxpBSCSQiDQA@mail.gmail.com> (raw)
In-Reply-To: <52d30372-44aa-153b-c69f-57150b6cf6b6@redhat.com>
On Sat, Nov 7, 2020 at 3:48 PM Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>
> 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?
From what I got, LPC IRQs and HPET IRQs do not usually overlap (IRQ
0,2,8 for HPET, IRQ 3-7,9+ for all ICH9), which means that connecting
them together will not create an issue. I don't know what will happen
if higher IRQ is chosen for HPET, but according to ICH9 spec, it seems
to be aware of HPET interrupts.
> 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.
>
>
prev parent reply other threads:[~2020-11-11 13:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-07 14:46 hw/i386/q35: Where go LPC irqs? Philippe Mathieu-Daudé
2020-11-11 12:58 ` Julia Suvorova [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMDeoFXmT3gdh5JOh5RopzYBjTTPwrHWZbHp0vwxpBSCSQiDQA@mail.gmail.com \
--to=jusual@redhat.com \
--cc=ehabkost@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).