Re: [Qemu-devel] [PATCH v4 00/11] Fix versatile_pci
On 8 July 2013 07:43, Rob Landley wrote: > On 06/29/2013 06:03:26 AM, Peter Maydell wrote: >> The "with the patch" case is uninteresting, because it's not >> actually a fix for anything, it's just a change that happened >> to work with old QEMU, and it's not a change that is in upstream >> Linux. > > > I want to create a kernel image that works with the existing QEMU image > people are likely to have installed on their systems, _and_ with current > versions of QEMU. > > Is that what you consider "uninteresting"? Interesting: * kernels which actually work on real hardware * mainline kernels which worked on old QEMU, because they're widely used Uninteresting: * local hacks which worked by fluke on old QEMU but won't work on the hardware * making mainline kernels which didn't work on old QEMU work by adapting to their bugginess (current vanilla mainline falls into the last of these categories) > I am trying to produce "an image that runs under qemu". That level of > genericity worked for several years, at least ever since 1.0. When it > stopped, I complained. You seem to be expressing incredulity at the concept. QEMU has always been free to improve its emulation to be closer to what the hardware does. If your guest doesn't work on the hardware it is always going to be liable to break. It's really common for new kernel changes to require new QEMU, because they tickle some bit of hardware emulation we had omitted or hadn't got right. If you want a kernel image that runs on older QEMU, stick with an older kernel. > I tried building a vanilla linux 3.10 kernel, and it doesn't work on qemu > 1.5. I confirmed their current interrupt mapping does not match any known > hardware or emulator, and that it changed more than once in incompatible > ways as they did wild-ass-guess du jour about what it should be now. Current vanilla works for the first PCI card, not for others. It behaves like this on both QEMU 1.4 and 1.5, ie these changes have not broken it further than it is already. > So I did the obvious-to-me thing and patched it back to how it _was_, which > is the only thing that works with previous versions of QEMU. You seem to > find this approach shocking and unexpected. You haven't patched it back like how it was, or it would work; old 2.x kernels work fine. Old kernels wrote 27 to PCI_INTERRUPT_LINE, not 59. >> "would work on real hardware". > > The stuff that's so rare the kernel guys couldn't find any to test on? They could, if they asked, if they cared. I actually went around and tested Arnd's patchset back in 2011. Nobody's ever asked me since. The point is that this patchset is a line in the sand -- we now have a defensible set of behaviour, because it's what the hardware does. Any future "hey, the kernel changed and broke things" can be directed straight at the kernel guys, because we're not changing any further unless it can be demonstrated that we don't run a kernel that's been tested on h/w. > Maybe I haven't been clear: I want something that works with current QEMU > _and_ old QEMU. > > Your paragraph above implies that there's smoething _different_ I can write > to PCI_INTERRUPT_LINE that will trigger the old behavior. So my patch to do > the old IRQ (which worked fine with qemu 1.2) needs to be bigger to humor > QEMU's heuristic. I'll try to figure out how to extend my patch to avoid > triggering your new "does not work" mode. The old mode is the broken one... > Let's see, stick a printf into qemu, and: > > =Write 60=12,59= > > So it's requesting IRQ 59, and QEMU's reponse is to _not_ give it IRQ 59 > unless we trigger the "broken" flag. > > So... real hardware doesn't get the IRQ it requests? Using the reqested IRQ > is "broken"? (Apparently your patch for a real hardware kernel doesn't > request the IRQ it's going to use? I'm confused...) On real hardware, PCI_INTERRUPT_LINE has no effect -- all it does is store a value for the kernel to read back. It has no effect on the interrupt routing. (This is true for any PCI controller.) However, the kernel happens to write a value which corresponds to what it *thinks* the hardware is wired up to. So we can use this to identify some of the mainline cases which expect old broken behaviour. > Right, easy enough to fix: > > --- a/arch/arm/mach-versatile/pci.c > +++ b/arch/arm/mach-versatile/pci.c > @@ -333,7 +333,13 @@ static int __init versatile_map_irq(const struct > pci_dev *dev, u8 slot, u8 pin) > > * 26 1 IRQ_SIC_PCI2 > * 27 1 IRQ_SIC_PCI3 > */ > - irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); > + // Hit QEMU 1.5.0 and later with a brick so it uses the IRQ we say. This comment is totally wrong. More accurate would be: // This code won't work on hardware because we still assume // the broken interrupt mapping used by old (pre 1.5.0) // versions of QEMU. Ensure that QEMU 1.5 is in its backward // compatibility mode by writing a definitely w
Re: [Qemu-devel] [PATCH v4 00/11] Fix versatile_pci
On 06/29/2013 06:03:26 AM, Peter Maydell wrote: On 28 June 2013 08:01, Rob Landley wrote: > Now that the next kernel's about to come out, I'm trying to get my arm > versatile image to work under qemu 1.5.0. The old kernel doesn't work, and > the current vanilla kernel doesn't work. This change broke it. > > I'm testing current linux-git both with and without this patch: > > --- linux/arch/arm/mach-versatile/pci.c 2013-04-28 19:36:01.0 -0500 > +++ linux.bak/arch/arm/mach-versatile/pci.c 2013-04-29 > 19:09:44.857097553 -0500 > @@ -333,7 +333,7 @@ > * 26 1 IRQ_SIC_PCI2 > * 27 1 IRQ_SIC_PCI3 > */ > - irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); > + irq = 59; //IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); > > return irq; > } > > With the patch, qemu 1.2.0 works, but qemu 1.5 versatile does not work with > or without the patch. The "with the patch" case is uninteresting, because it's not actually a fix for anything, it's just a change that happened to work with old QEMU, and it's not a change that is in upstream Linux. I want to create a kernel image that works with the existing QEMU image people are likely to have installed on their systems, _and_ with current versions of QEMU. Is that what you consider "uninteresting"? > Here's a test image to demonstrate the problem: it works fine under qemu > 1.2.0, but doesn't under 1.5.0: > > http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2 > > Extract it and ./run-emulator.sh. You get a shell prompt from 1.2.0, from > 1.5.0 it never gets a scsi interrupt, and after a timeout goes into an > abort/reset loop. Is this an image with your patch or without it? Does it work if you use the -global option to force legacy IRQ mapping? Under qemu 1.2? It goes: qemu-system-arm: Property '.broken-irq-mapping' not found See "backwards compatability", above. I am trying to produce "an image that runs under qemu". That level of genericity worked for several years, at least ever since 1.0. When it stopped, I complained. You seem to be expressing incredulity at the concept. >> >> This version of the patchset avoids breaking legacy Linux guests >> >> by automatically detecting those broken kernels and switching back >> >> to the old mapping. > > > As testing with the above image confirms: it does not. I tested with several separate variants of the Linux kernel. I tried building a vanilla linux 3.10 kernel, and it doesn't work on qemu 1.5. I confirmed their current interrupt mapping does not match any known hardware or emulator, and that it changed more than once in incompatible ways as they did wild-ass-guess du jour about what it should be now. The fact it was obviously untested (or it wouldn't keep changing, since there presumably is just one right answer) says to me that this hardware is difficult ot come by. (The fact the IRQ spent over 5 years in the old state before anyone noticed would also imply a lack of test hardware.) However, it's useful to emulate because you can stick a PCI bus in it, meaning you can stick arbitrary devices (hard drive and network card) into said bus. So I did the obvious-to-me thing and patched it back to how it _was_, which is the only thing that works with previous versions of QEMU. You seem to find this approach shocking and unexpected. Do you have a better way to achieve compatability with older versions of qemu _and_ current versions? (I'm open to suggestions...) >> >> This works by looking at the values the kernel >> >> writes to the PCI_INTERRUPT_LINE register in the config space, which >> >> is effectively the interrupt number the kernel expects the device >> >> to be using. If this doesn't match reality we use the broken mapping. >> >> (Thanks to Michael S. Tsirkin for this suggestion.) > > Define "reality". "would work on real hardware". The stuff that's so rare the kernel guys couldn't find any to test on? Maybe I haven't been clear: I want something that works with current QEMU _and_ old QEMU. Your paragraph above implies that there's smoething _different_ I can write to PCI_INTERRUPT_LINE that will trigger the old behavior. So my patch to do the old IRQ (which worked fine with qemu 1.2) needs to be bigger to humor QEMU's heuristic. I'll try to figure out how to extend my patch to avoid triggering your new "does not work" mode. Let's see, stick a printf into qemu, and: =Write 60=12,59= So it's requesting IRQ 59, and QEMU's reponse is to _not_ give it IRQ 59 unless we trigger the "broken" flag. So... real hardware doesn't get the IRQ it requests? Using the reqested IRQ is "broken"? (Apparently your patch for a real hardware kernel doesn't request the IRQ it's going to use? I'm confused...) Right, easy enough to fix: --- a/arch/arm/mach-versatile/pci.c +++ b/arch/arm/mach-versatile/pci.c @@ -333,7 +333,13 @@ static int
Re: [Qemu-devel] [PATCH v4 00/11] Fix versatile_pci
On 28 June 2013 08:01, Rob Landley wrote: > Now that the next kernel's about to come out, I'm trying to get my arm > versatile image to work under qemu 1.5.0. The old kernel doesn't work, and > the current vanilla kernel doesn't work. This change broke it. Nope. Current vanilla is busted under QEMU-1.4-and-earlier behaviour too: the first PCI device will work but second and subsequent won't. The behaviour with QEMU 1.5 is the same. This is simply and straightforwardly a kernel bug and you need to get the kernel folk to fix it, preferably by actually writing PCI code which works on the hardware. -- PMM
Re: [Qemu-devel] [PATCH v4 00/11] Fix versatile_pci
On 28 June 2013 08:01, Rob Landley wrote: > Now that the next kernel's about to come out, I'm trying to get my arm > versatile image to work under qemu 1.5.0. The old kernel doesn't work, and > the current vanilla kernel doesn't work. This change broke it. > > I'm testing current linux-git both with and without this patch: > > --- linux/arch/arm/mach-versatile/pci.c 2013-04-28 19:36:01.0 -0500 > +++ linux.bak/arch/arm/mach-versatile/pci.c 2013-04-29 > 19:09:44.857097553 -0500 > @@ -333,7 +333,7 @@ > * 26 1 IRQ_SIC_PCI2 > * 27 1 IRQ_SIC_PCI3 > */ > - irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); > + irq = 59; //IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); > > return irq; > } > > With the patch, qemu 1.2.0 works, but qemu 1.5 versatile does not work with > or without the patch. The "with the patch" case is uninteresting, because it's not actually a fix for anything, it's just a change that happened to work with old QEMU, and it's not a change that is in upstream Linux. > Here's a test image to demonstrate the problem: it works fine under qemu > 1.2.0, but doesn't under 1.5.0: > > http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2 > > Extract it and ./run-emulator.sh. You get a shell prompt from 1.2.0, from > 1.5.0 it never gets a scsi interrupt, and after a timeout goes into an > abort/reset loop. Is this an image with your patch or without it? Does it work if you use the -global option to force legacy IRQ mapping? >> >> This version of the patchset avoids breaking legacy Linux guests >> >> by automatically detecting those broken kernels and switching back >> >> to the old mapping. > > > As testing with the above image confirms: it does not. I tested with several separate variants of the Linux kernel. >> >> This works by looking at the values the kernel >> >> writes to the PCI_INTERRUPT_LINE register in the config space, which >> >> is effectively the interrupt number the kernel expects the device >> >> to be using. If this doesn't match reality we use the broken mapping. >> >> (Thanks to Michael S. Tsirkin for this suggestion.) > > > Define "reality". "would work on real hardware". > The kernel changed what irqs it was expecting _three_times_ last year, and > as far as I can tell none of them were what they were _trying_ to do. > > Here's my blog entry and the source control comments where I diagnosed this > stuff to show that the kernel guys have no flipping CLUE how an arm > versatile board actually works: I agree that the kernel has made a bit of a mess in this area, so we don't need to have that argument again. > The kernel code in this area is CRAP, has changed multiple times in > semi-random ways, has obviously NEVER been tested on real hardware, and if > you've implemented what the actual versatile documentation says it's clearly > not what the kernel is doing. I tested these changes against a patchset which Arnd wrote which I can guarantee was tested on real hardware because I did the testing myself. > Do you have a kernel that runs under current qemu arm versatile emulation? I > can poke around and figure out which irqs it expects _now_, but it's not > "right" and presumably you're just going to change it again when you realize > what qemu is doing and what the unpatched kernel is doing don't match. The ones on http://people.debian.org/~aurel32/qemu/armel/ should work. -- PMM
Re: [Qemu-devel] [PATCH v4 00/11] Fix versatile_pci
On 04/08/2013 03:16:18 PM, Peter Maydell wrote: On 8 April 2013 18:37, Rob Landley wrote: > On 04/06/2013 10:44:25 AM, Peter Maydell wrote: >> >> This patch series fixes a number of serious bugs in our emulation of >> the PCI controller found on VersatilePB and the early Realview boards: >> * our interrupt mapping was totally wrong > > > Yes. Yes it was. However, what you were doing matched the kernel for many > years. > The kernel guys have screwed this up three consecutive times, as described > here: > > http://landley.net/hg/aboriginal/rev/7bf850767bb8 > > Because as far as I can tell, nobody has any test hardware for this anymore. There is some but it's pretty rare. Now that the next kernel's about to come out, I'm trying to get my arm versatile image to work under qemu 1.5.0. The old kernel doesn't work, and the current vanilla kernel doesn't work. This change broke it. I'm testing current linux-git both with and without this patch: --- linux/arch/arm/mach-versatile/pci.c 2013-04-28 19:36:01.0 -0500 +++ linux.bak/arch/arm/mach-versatile/pci.c 2013-04-29 19:09:44.857097553 -0500 @@ -333,7 +333,7 @@ * 26 1 IRQ_SIC_PCI2 * 27 1 IRQ_SIC_PCI3 */ - irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); + irq = 59; //IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); return irq; } With the patch, qemu 1.2.0 works, but qemu 1.5 versatile does not work with or without the patch. Here's a test image to demonstrate the problem: it works fine under qemu 1.2.0, but doesn't under 1.5.0: http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2 Extract it and ./run-emulator.sh. You get a shell prompt from 1.2.0, from 1.5.0 it never gets a scsi interrupt, and after a timeout goes into an abort/reset loop. >> This version of the patchset avoids breaking legacy Linux guests >> by automatically detecting those broken kernels and switching back >> to the old mapping. As testing with the above image confirms: it does not. >> This works by looking at the values the kernel >> writes to the PCI_INTERRUPT_LINE register in the config space, which >> is effectively the interrupt number the kernel expects the device >> to be using. If this doesn't match reality we use the broken mapping. >> (Thanks to Michael S. Tsirkin for this suggestion.) Define "reality". The kernel changed what irqs it was expecting _three_times_ last year, and as far as I can tell none of them were what they were _trying_ to do. Here's my blog entry and the source control comments where I diagnosed this stuff to show that the kernel guys have no flipping CLUE how an arm versatile board actually works: 1) http://landley.net/notes-2013.html#15-03-2013 2) http://landley.net/hg/aboriginal/rev/1588 3) http://landley.net/hg/aboriginal/rev/1589 Here's the text from #2: = The arm guys have now screwed up the ARM versatile board's IRQ routing three consecutive times. I'm impressed. The ARM versatile scsi IRQ is position 27 on the IRQ controller. That's what QEMU implemented, that's what worked for years. In commit 1bc39ac5dab2 the kernel guys screwed up their math (among other things doing -24 and then &3 on the result.. can we say NOP?) so it was now trying to use IRQ 28 once the unnecessary "swizzle" function got done with it. (I started reverting that 6 months ago in aboriginal changeset 1534.) Then in commit f5565295892e they incremented the IRQ controller start by 32... and didn't adjust map_irq() so it was still requesting 28, now before the start of the IRQ controller's range. Then in commit e3e92a7be693 they noticed it was broken, and added 64 to it. (So now it's requesting 64+28=92, when it _should_ be requesting 32+27=59. Their own description of what changed does not support what the patch did, and yet...) = All that was about the SCSI IRQ. Entry #3 above was about the _ethernet_ IRQ, which they screwed up in a different way (they did an &3 in a way that wrapped)about how they did the math for the ethernet irq wrong in a _different_ way than they did the scsi irq math wrong. The line that's actually calculating the IRQ is: irq = 27 + ((slot - 24 + pin - 1) & 3); Since 24 is divisible by 3, subtracting 24 and then & 3 on the result is a NOP so this math can't POSSIBLY do what they think it's doing. The kernel code in this area is CRAP, has changed multiple times in semi-random ways, has obviously NEVER been tested on real hardware, and if you've implemented what the actual versatile documentation says it's clearly not what the kernel is doing. > My concern here was that you'd going to change qemu so it doesn't run the > old images, and require a very new qemu to run the new images, so there will > be an incompatible flag day. No, it doesn't break old images, as the paragraph you quote clearly states. Yes, if the kernel guys fix the kernel yo
Re: [Qemu-devel] [PATCH v4 00/11] Fix versatile_pci
On 8 April 2013 18:37, Rob Landley wrote: > On 04/06/2013 10:44:25 AM, Peter Maydell wrote: >> >> This patch series fixes a number of serious bugs in our emulation of >> the PCI controller found on VersatilePB and the early Realview boards: >> * our interrupt mapping was totally wrong > > > Yes. Yes it was. However, what you were doing matched the kernel for many > years. > The kernel guys have screwed this up three consecutive times, as described > here: > > http://landley.net/hg/aboriginal/rev/7bf850767bb8 > > Because as far as I can tell, nobody has any test hardware for this anymore. There is some but it's pretty rare. >> This version of the patchset avoids breaking legacy Linux guests >> by automatically detecting those broken kernels and switching back >> to the old mapping. This works by looking at the values the kernel >> writes to the PCI_INTERRUPT_LINE register in the config space, which >> is effectively the interrupt number the kernel expects the device >> to be using. If this doesn't match reality we use the broken mapping. >> (Thanks to Michael S. Tsirkin for this suggestion.) > > > My concern here was that you'd going to change qemu so it doesn't run the > old images, and require a very new qemu to run the new images, so there will > be an incompatible flag day. No, it doesn't break old images, as the paragraph you quote clearly states. Yes, if the kernel guys fix the kernel you'll need a newer QEMU to run that. However as the kernel patches have been floating around unapplied since 2011 you can draw your own conclusions about how quickly the kernel will get fixed. > Yay improving the latest and greatest, but when I'm regression testing as > many different platforms as I can get working, stuff tends to break. (The > most recent target-specific one for me on the QEMU side was probably the > powerpc video thing, > http://landley.net/notes-2012.html#17-11-2012 . Other than the 1.3/1.4 > general TCG instability which was the translation unit size being calculated > wrong.) This is why I can't demand my users upgrade each time I do a > release: the target they're interested in might not work because my images > depend on things you don't regression test much. Yes, TCG and minor platform emulation is to some extent on a 'best effort' basis. Unfortunately we have neither the developer resources nor the automated test infrastructure to do better; if you can help on either front do say. > I'm glad to see you're addressing backwards compatability, but it looks like > I might have to patch my kernels to write the _old_ value to this register > in order to get something that runs on old qemu? If you want to run on a QEMU predating this patchset then you need to have a kernel which expects the old and broken behaviour, yes. This patchset is to some extent futureproofing in that it ensures that if the kernel guys actually fix the versatilepb PCI code at some future date the QEMU that is out in the wild will still cope. > Because I broke my kernel > to fit what qemu was doing, and I dunno when this register write changed. (I > _do_ know that what the kernel guys have been doing to versatile is insane > and inconsistent, and if you change your code to humor them they'll probably > break it again. Their register mapping in 3.8 was so wrong even _I_ could > tell.) I don't have any interest in adding workarounds to QEMU for kernel versions which didn't work on any QEMU version or on real hardware. I do care about making QEMU work like the hardware, and about keeping it working with kernels that assume the old longstanding QEMU behaviour. This patchset satisfies both those goals. If you have issues with the kernel breaking things then you need to take it up with the kernel developers. -- PMM
Re: [Qemu-devel] [PATCH v4 00/11] Fix versatile_pci
On 04/06/2013 10:44:25 AM, Peter Maydell wrote: This patch series fixes a number of serious bugs in our emulation of the PCI controller found on VersatilePB and the early Realview boards: * our interrupt mapping was totally wrong Yes. Yes it was. However, what you were doing matched the kernel for many years. I build system images that are working on versatilePB right now, with the 3.8 kernel. http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2 Grab that, ./run-emulator.sh and it should boot to a shell prompt within which you can compile hello world. The kernel guys have screwed this up three consecutive times, as described here: http://landley.net/hg/aboriginal/rev/7bf850767bb8 Because as far as I can tell, nobody has any test hardware for this anymore. (But no other board emulation I've tried lets me stick a PCI bus and a scsi controller, ethernet, and serial port into an arm board along with enough memory to natively compile stuff.) This past release I tried to fix it up properly: http://landley.net/notes.html#15-03-2013 http://landley.net/notes.html#16-03-2013 And then I gave up and hit it with a rock: http://landley.net/hg/aboriginal/rev/96fb8598a446 This version of the patchset avoids breaking legacy Linux guests by automatically detecting those broken kernels and switching back to the old mapping. This works by looking at the values the kernel writes to the PCI_INTERRUPT_LINE register in the config space, which is effectively the interrupt number the kernel expects the device to be using. If this doesn't match reality we use the broken mapping. (Thanks to Michael S. Tsirkin for this suggestion.) My concern here was that you'd going to change qemu so it doesn't run the old images, and require a very new qemu to run the new images, so there will be an incompatible flag day. This is especially a concern for me because I had to go back to qemu 1.2.0 to get stable builds on all my targets, because the 1.3.0 and 1.4.0 releases were both broken: http://landley.net/aboriginal/news.html Yay improving the latest and greatest, but when I'm regression testing as many different platforms as I can get working, stuff tends to break. (The most recent target-specific one for me on the QEMU side was probably the powerpc video thing, http://landley.net/notes-2012.html#17-11-2012 . Other than the 1.3/1.4 general TCG instability which was the translation unit size being calculated wrong.) This is why I can't demand my users upgrade each time I do a release: the target they're interested in might not work because my images depend on things you don't regression test much. I'm glad to see you're addressing backwards compatability, but it looks like I might have to patch my kernels to write the _old_ value to this register in order to get something that runs on old qemu? Because I broke my kernel to fit what qemu was doing, and I dunno when this register write changed. (I _do_ know that what the kernel guys have been doing to versatile is insane and inconsistent, and if you change your code to humor them they'll probably break it again. Their register mapping in 3.8 was so wrong even _I_ could tell.) Rob
[Qemu-devel] [PATCH v4 00/11] Fix versatile_pci
This patch series fixes a number of serious bugs in our emulation of the PCI controller found on VersatilePB and the early Realview boards: * our interrupt mapping was totally wrong * we weren't implementing the PCI memory windows * the I/O window wasn't mapped on VersatilePB * realview mapped things at the wrong addresses * we didn't implement the controller's registers at all It also updates to some reasonable approximation to QOM best practice, including subclassing pci_host rather than doing everything by hand. I haven't implemented support for the SMAP registers (which control how the controller converts accesses made by bus-mastering PCI devices into system addresses). For the moment we rely on the fact that Linux always maps things 1:1. (It wouldn't be too hard to add SMAP support but it requires changing QEMU's pci code to allow a controller to pass in a MemoryRegion* for DMA to use instead of the system address space, so I prefer to leave that for another series.) Patchset tested on both versatilepb and realview, using a set of Linux kernel patches written by Arnd Bergmann: http://lists.infradead.org/pipermail/linux-arm-kernel/2010-October/029040.html which were in turn tested against real PB926 and PB1176 hardware. This version of the patchset avoids breaking legacy Linux guests by automatically detecting those broken kernels and switching back to the old mapping. This works by looking at the values the kernel writes to the PCI_INTERRUPT_LINE register in the config space, which is effectively the interrupt number the kernel expects the device to be using. If this doesn't match reality we use the broken mapping. (Thanks to Michael S. Tsirkin for this suggestion.) If the kernel ever writes something different to the old kernel then QEMU will assume it is dealing with a working kernel and will stop looking for broken values. This allows a new kernel to put any values it likes in PCI_INTERRUPT_LINE, provided its init code does an initial write of something other than 27 to let QEMU know it can cope with the correct irq mapping. Changes v3->v4: * rebase following recent pci changes * patch 7 minor tweaks as per mst review: added VPB_PCI prefix to enum names, drop specified values drop unnecessary casts of void* Changes v2->v3: * patch 7: make broken guest autodetect a one-time thing rather than reversible, to allow more flexibility in how new kernels choose to use the PCI_INTERRUPT_LINE registers Changes v1->v2: * autodetect broken guests rather than using user-set property * use pci_swizzle_map_fn * new patch: drop unnecessary vpb_pci_config_addr() function Peter Maydell (11): versatile_pci: Fix hardcoded tabs versatile_pci: Expose PCI I/O region on Versatile PB versatile_pci: Update to realize and instance init functions versatile_pci: Change to subclassing TYPE_PCI_HOST_BRIDGE versatile_pci: Use separate PCI I/O space rather than system I/O space versatile_pci: Put the host bridge PCI device at slot 29 versatile_pci: Implement the correct PCI IRQ mapping versatile_pci: Implement the PCI controller's control registers arm/realview: Fix mapping of PCI regions versatile_pci: Expose PCI memory space to system hw/versatile_pci: Drop unnecessary vpb_pci_config_addr() hw/arm/realview.c| 22 +-- hw/arm/versatilepb.c | 11 +- hw/versatile_pci.c | 399 -- 3 files changed, 371 insertions(+), 61 deletions(-) -- 1.7.9.5
