All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: "Hervé Poussineau" <hpoussin@reactos.org>,
	"Bernhard Beschow" <shentey@gmail.com>,
	qemu-devel@nongnu.org, "Aurelien Jarno" <aurelien@aurel32.net>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: [PATCH v2 4/5] isa/piix4: Fix PCI IRQ levels to be preserved in VMState
Date: Sat, 12 Feb 2022 16:41:45 +0000	[thread overview]
Message-ID: <CAFEAcA9BBFHH7eqzB_zW-VDZWuXDEkYUb=P1ocPn_UyaZZFZ3w@mail.gmail.com> (raw)
In-Reply-To: <ebb5f8ad-64dc-8349-4d1c-7d8b623d60b2@eik.bme.hu>

On Sat, 12 Feb 2022 at 13:42, BALATON Zoltan <balaton@eik.bme.hu> wrote:
> By the way the corresponding member in struct PIIXState in
> include/hw/southbridge/piix.h has a comment saying:
>
>      /* This member isn't used. Just for save/load compatibility */
>      int32_t pci_irq_levels_vmstate[PIIX_NUM_PIRQS];
>
> and only seems to be filled in piix3_pre_save() but never used. So what's
> the point of this then? Maybe piix3 also uses a bitmap to store these
> levels instead? There's a uint64_t pic_levels member above the unused
> array but I haven't checked the implementation.

I think what has happened here is that originally piix3 used
the same implementation piix4 currently does -- where it stores
locally the value of the (incoming) PCI IRQ levels, and then when it wants
to know the value of the (outgoing) PIC IRQ levels it loops round
to effectively OR together all the PCI IRQ levels for those PCI
IRQs which are configured to that particular PIC interrupt.

Then in commit e735b55a8c11 (in 2011) piix3 was changed to call
pci_bus_get_irq_level() to get the value of a PCI IRQ rather than
looking at its local cache of that information in the pci_irq_levels[]
array. This is the source of the "save/load compatibility" thing --
before doing a vmsave piix3_pre_save() fills in that field so that
it appears in the outbound data stream and thus a migration from
a new QEMU to an old pre-e735b55a8c11 QEMU will still work. (This
was important at the time, but could probably be cleaned up now.)

The next commit after that one is ab431c283e7055bcd, which
is an optimization that fixes the equivalent of the "XXX: optimize"
marker in the gt64120_pci_set_irq()/piix4 code -- this does
something slightly more complicated involving the pic_levels
field, in order to avoid having to do the "loop over all the
PCI IRQ levels" whenever it needs to set/reset a PIC interrupt.

We could pick up one or both (or none!) of these two changes
for the piix4 code. (If we're breaking migration compat anyway
we wouldn't need to include the save-load compat part of
the first change.)

thanks
-- PMM


  reply	other threads:[~2022-02-12 16:42 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-12 11:35 [PATCH v2 0/5] malta: Fix PCI IRQ levels to be preserved during migration Bernhard Beschow
2022-02-12 11:35 ` [PATCH v2 1/5] malta: Move PCI interrupt handling from gt64xxx to piix4 Bernhard Beschow
2022-02-12 13:18   ` BALATON Zoltan
2022-02-12 16:44     ` BALATON Zoltan
2022-02-13 14:21       ` Bernhard Beschow
2022-02-13 14:34     ` Bernhard Beschow
2022-02-12 11:35 ` [PATCH v2 2/5] pci: Always pass own DeviceState to pci_map_irq_fn's Bernhard Beschow
2022-02-12 13:27   ` BALATON Zoltan
2022-02-12 14:23     ` Bernhard Beschow
2022-02-12 16:13       ` BALATON Zoltan
2022-02-13 14:31         ` Bernhard Beschow
2022-02-13 15:22           ` BALATON Zoltan
2022-02-12 16:16     ` Peter Maydell
2022-02-12 11:35 ` [PATCH v2 3/5] isa/piix4: Resolve global variables Bernhard Beschow
2022-02-12 11:35 ` [PATCH v2 4/5] isa/piix4: Fix PCI IRQ levels to be preserved in VMState Bernhard Beschow
2022-02-12 13:42   ` BALATON Zoltan
2022-02-12 16:41     ` Peter Maydell [this message]
2022-02-12 17:02       ` BALATON Zoltan
2022-02-12 18:30         ` Peter Maydell
2022-02-12 21:44           ` BB
2022-02-12 21:46           ` Bernhard Beschow
2022-02-12 11:35 ` [PATCH v2 5/5] isa/piix4: Resolve redundant i8259[] attribute Bernhard Beschow
2022-02-12 13:19   ` BALATON Zoltan
2022-02-12 14:02     ` BB
2022-02-12 14:05     ` Bernhard Beschow
2022-02-12 15:57       ` BALATON Zoltan
2022-02-12 15:58         ` BALATON Zoltan

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='CAFEAcA9BBFHH7eqzB_zW-VDZWuXDEkYUb=P1ocPn_UyaZZFZ3w@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=aurelien@aurel32.net \
    --cc=balaton@eik.bme.hu \
    --cc=f4bug@amsat.org \
    --cc=hpoussin@reactos.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shentey@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.