From: "Michael S. Tsirkin" <mst@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
patches@linaro.org, "Will Deacon" <will.deacon@arm.com>,
qemu-devel@nongnu.org, "Paul Brook" <paul@codesourcery.com>,
"Andreas Färber" <afaerber@suse.de>,
"Aurelien Jarno" <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [PATCH v2 07/11] versatile_pci: Implement the correct PCI IRQ mapping
Date: Thu, 4 Apr 2013 13:58:14 +0300 [thread overview]
Message-ID: <20130404105814.GA6328@redhat.com> (raw)
In-Reply-To: <CAFEAcA8YfnUGahWVVz+7A==Hp=C-AjejGhXyqX9NE6vG8YZtqA@mail.gmail.com>
On Thu, Apr 04, 2013 at 12:05:51PM +0100, Peter Maydell wrote:
> On 28 March 2013 10:28, Peter Maydell <peter.maydell@linaro.org> wrote:
> > On 26 March 2013 21:12, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> On Tue, Mar 26, 2013 at 11:17:55AM +0000, Peter Maydell wrote:
> >>> I'm happy to provide some other way for QEMU to detect a
> >>> new working kernel if you want to implement one in the
> >>> kernel, if that's cleaner.
> >>
> >> That's why I suggested writing some number at offset 0x08
> >> (that's revision ID) in configuration space of device 0 on bus 0.
> >> It's guaranteed harmless on real hardware and QEMU could detect this
> >> write and say "aha new kernel, even though it uses #27".
> >
> > OK, that makes sense.
>
> In fact I've just realised that "allow new kernels to use #27
> without getting the back-compat broken irq mapping" conflicts
> with "allow new kernels to kexec old broken kernels".
Could you clarify why, pls? Also - does this really matter so much?
kexec between version is always a risky affair...
> So the
> easiest approach is just to drop the code which allows us to
> switch back to broken mode again. Then the new kernel's init
> code can force non-broken mode by writing something other than
> #27 to some device's PCI_INTERRUPT_LINE register, and then
> is free to use #27 if it wants to.
>
> -- PMM
I'm fine with this too.
next prev parent reply other threads:[~2013-04-04 11:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 10:22 [Qemu-devel] [PATCH v2 00/11] Fix versatile_pci (now without breaking linux) Peter Maydell
2013-03-26 10:22 ` [Qemu-devel] [PATCH v2 01/11] versatile_pci: Fix hardcoded tabs Peter Maydell
2013-03-26 10:22 ` [Qemu-devel] [PATCH v2 02/11] versatile_pci: Expose PCI I/O region on Versatile PB Peter Maydell
2013-03-26 10:22 ` [Qemu-devel] [PATCH v2 03/11] versatile_pci: Update to realize and instance init functions Peter Maydell
2013-03-26 10:22 ` [Qemu-devel] [PATCH v2 04/11] versatile_pci: Change to subclassing TYPE_PCI_HOST_BRIDGE Peter Maydell
2013-03-26 10:22 ` [Qemu-devel] [PATCH v2 05/11] versatile_pci: Use separate PCI I/O space rather than system I/O space Peter Maydell
2013-03-26 10:22 ` [Qemu-devel] [PATCH v2 06/11] versatile_pci: Put the host bridge PCI device at slot 29 Peter Maydell
2013-03-26 10:22 ` [Qemu-devel] [PATCH v2 07/11] versatile_pci: Implement the correct PCI IRQ mapping Peter Maydell
2013-03-26 10:54 ` Arnd Bergmann
2013-03-26 11:00 ` Peter Maydell
2013-03-26 11:08 ` Arnd Bergmann
2013-03-26 11:17 ` Peter Maydell
2013-03-26 21:12 ` Michael S. Tsirkin
2013-03-28 10:28 ` Peter Maydell
2013-04-04 11:05 ` Peter Maydell
2013-04-04 10:58 ` Michael S. Tsirkin [this message]
2013-04-04 12:16 ` Peter Maydell
2013-05-14 11:45 ` Peter Maydell
2013-03-26 10:22 ` [Qemu-devel] [PATCH v2 08/11] versatile_pci: Implement the PCI controller's control registers Peter Maydell
2013-03-26 10:22 ` [Qemu-devel] [PATCH v2 09/11] arm/realview: Fix mapping of PCI regions Peter Maydell
2013-03-26 10:22 ` [Qemu-devel] [PATCH v2 10/11] versatile_pci: Expose PCI memory space to system Peter Maydell
2013-03-26 10:22 ` [Qemu-devel] [PATCH v2 11/11] hw/versatile_pci: Drop unnecessary vpb_pci_config_addr() Peter Maydell
2013-03-28 13:20 ` [Qemu-devel] [PATCH v2 00/11] Fix versatile_pci (now without breaking linux) Paul Brook
2013-03-28 13:23 ` Peter Maydell
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=20130404105814.GA6328@redhat.com \
--to=mst@redhat.com \
--cc=afaerber@suse.de \
--cc=arnd@arndb.de \
--cc=aurelien@aurel32.net \
--cc=patches@linaro.org \
--cc=paul@codesourcery.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=will.deacon@arm.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 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).