hw/ide/via.c | 31 ++++++++--- hw/isa/vt82c686.c | 27 +++++----- hw/mips/fuloong2e.c | 35 +++--------- hw/southbridge/vt82c686.c | 107 +++++++++++++++++++++++++++++++++++++ MAINTAINERS | 1 + hw/Kconfig | 1 + hw/isa/Kconfig | 9 ---- hw/meson.build | 1 + hw/southbridge/Kconfig | 8 +++ hw/southbridge/meson.build | 1 + 10 files changed, 164 insertions(+), 57 deletions(-) create mode 100644 hw/southbridge/vt82c686.c create mode 100644 hw/southbridge/Kconfig create mode 100644 hw/southbridge/meson.build
The motivation behind this series is to remove the isa_get_irq(NULL) call to simplify the ISA generic model. Since v1: - rebased on top of remotes/dg-gitlab/tags/ppc-for-6.1-20210504 Philippe Mathieu-Daudé (6): hw/isa/vt82c686: Name output IRQ as 'intr' hw/isa/vt82c686: Simplify removing unuseful qemu_allocate_irqs() call hw/isa/vt82c686: Let ISA function expose ISA IRQs hw/ide/via: Replace magic 2 value by ARRAY_SIZE / MAX_IDE_DEVS hw/ide/via: Connect IDE function output IRQs to the ISA function input hw/southbridge/vt82c686: Introduce VT82C686B_SOUTHBRIDGE hw/ide/via.c | 31 ++++++++--- hw/isa/vt82c686.c | 27 +++++----- hw/mips/fuloong2e.c | 35 +++--------- hw/southbridge/vt82c686.c | 107 +++++++++++++++++++++++++++++++++++++ MAINTAINERS | 1 + hw/Kconfig | 1 + hw/isa/Kconfig | 9 ---- hw/meson.build | 1 + hw/southbridge/Kconfig | 8 +++ hw/southbridge/meson.build | 1 + 10 files changed, 164 insertions(+), 57 deletions(-) create mode 100644 hw/southbridge/vt82c686.c create mode 100644 hw/southbridge/Kconfig create mode 100644 hw/southbridge/meson.build -- 2.26.3
On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: > The motivation behind this series is to remove the > isa_get_irq(NULL) call to simplify the ISA generic model. > > Since v1: > - rebased on top of remotes/dg-gitlab/tags/ppc-for-6.1-20210504 I'll try to have a look at these later but some notes: The pegasos2 changes are now in master so if this was before that maybe rebasing on master is now enough. However I wonder if any changes to pegasos2.c is needed due to changed init of the chip model or is that only affecting 82c686b? Please also note that pegasos2 is not enabled by default due to needing undistributable firmware ROM so to test it you need to enable it in default-configs/devices/ppc-softmmu.mak Regards, BALATON Zoltan > Philippe Mathieu-Daudé (6): > hw/isa/vt82c686: Name output IRQ as 'intr' > hw/isa/vt82c686: Simplify removing unuseful qemu_allocate_irqs() call > hw/isa/vt82c686: Let ISA function expose ISA IRQs > hw/ide/via: Replace magic 2 value by ARRAY_SIZE / MAX_IDE_DEVS > hw/ide/via: Connect IDE function output IRQs to the ISA function input > hw/southbridge/vt82c686: Introduce VT82C686B_SOUTHBRIDGE > > hw/ide/via.c | 31 ++++++++--- > hw/isa/vt82c686.c | 27 +++++----- > hw/mips/fuloong2e.c | 35 +++--------- > hw/southbridge/vt82c686.c | 107 +++++++++++++++++++++++++++++++++++++ > MAINTAINERS | 1 + > hw/Kconfig | 1 + > hw/isa/Kconfig | 9 ---- > hw/meson.build | 1 + > hw/southbridge/Kconfig | 8 +++ > hw/southbridge/meson.build | 1 + > 10 files changed, 164 insertions(+), 57 deletions(-) > create mode 100644 hw/southbridge/vt82c686.c > create mode 100644 hw/southbridge/Kconfig > create mode 100644 hw/southbridge/meson.build > > -- > 2.26.3 > > >
Hi Zoltan, On 5/11/21 1:28 PM, BALATON Zoltan wrote: > On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: >> The motivation behind this series is to remove the >> isa_get_irq(NULL) call to simplify the ISA generic model. >> >> Since v1: >> - rebased on top of remotes/dg-gitlab/tags/ppc-for-6.1-20210504 > > I'll try to have a look at these later but some notes: The pegasos2 > changes are now in master so if this was before that maybe rebasing on > master is now enough. This is what this series does, simply rebase on top of your merged patches. > However I wonder if any changes to pegasos2.c is > needed due to changed init of the chip model or is that only affecting > 82c686b? There is no change in 'init' in this series, it is only QOM boilerplate code churn, no logical change intended. > Please also note that pegasos2 is not enabled by default due to > needing undistributable firmware ROM so to test it you need to enable it > in default-configs/devices/ppc-softmmu.mak I remember you said you were mostly interested in the VT8231, not the VT82C686. This series only QOM'ify the latter. What is your idea? Send the firmware off-list and explain how the OS works and how (what) to test? Regards, Phil. >> Philippe Mathieu-Daudé (6): >> hw/isa/vt82c686: Name output IRQ as 'intr' >> hw/isa/vt82c686: Simplify removing unuseful qemu_allocate_irqs() call >> hw/isa/vt82c686: Let ISA function expose ISA IRQs >> hw/ide/via: Replace magic 2 value by ARRAY_SIZE / MAX_IDE_DEVS >> hw/ide/via: Connect IDE function output IRQs to the ISA function input >> hw/southbridge/vt82c686: Introduce VT82C686B_SOUTHBRIDGE
On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: > Hi Zoltan, > > On 5/11/21 1:28 PM, BALATON Zoltan wrote: >> On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: >>> The motivation behind this series is to remove the >>> isa_get_irq(NULL) call to simplify the ISA generic model. >>> >>> Since v1: >>> - rebased on top of remotes/dg-gitlab/tags/ppc-for-6.1-20210504 >> >> I'll try to have a look at these later but some notes: The pegasos2 >> changes are now in master so if this was before that maybe rebasing on >> master is now enough. > > This is what this series does, simply rebase on top of your merged > patches. > >> However I wonder if any changes to pegasos2.c is >> needed due to changed init of the chip model or is that only affecting >> 82c686b? > > There is no change in 'init' in this series, it is only QOM boilerplate > code churn, no logical change intended. > >> Please also note that pegasos2 is not enabled by default due to >> needing undistributable firmware ROM so to test it you need to enable it >> in default-configs/devices/ppc-softmmu.mak > > I remember you said you were mostly interested in the VT8231, not > the VT82C686. This series only QOM'ify the latter. OK as I said I haven't looked at it in detail. > What is your idea? Send the firmware off-list and explain how > the OS works and how (what) to test? I've already sent you this info: https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg01553.html but I can't write a test case so if you want to automate this and make it part of QEMU tests then some help with that would be appreciated. As for the firmware, once Alexey's VOF (Virtual Open Firmware, minimial OF emulation in QEMU) is merged I plan to try to use that to make it possible to boot some guests with that so no firmware image would be needed and pegasos2 could be enabled by default. But for now a firmware image is needed as guests expect an OF environment to boot. Regards, BALATON Zoltan
On 5/11/21 3:09 PM, BALATON Zoltan wrote: > On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: >> Hi Zoltan, >> >> On 5/11/21 1:28 PM, BALATON Zoltan wrote: >>> On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: >>>> The motivation behind this series is to remove the >>>> isa_get_irq(NULL) call to simplify the ISA generic model. >>>> >>>> Since v1: >>>> - rebased on top of remotes/dg-gitlab/tags/ppc-for-6.1-20210504 >>> >>> I'll try to have a look at these later but some notes: The pegasos2 >>> changes are now in master so if this was before that maybe rebasing on >>> master is now enough. >> >> This is what this series does, simply rebase on top of your merged >> patches. >> >>> However I wonder if any changes to pegasos2.c is >>> needed due to changed init of the chip model or is that only affecting >>> 82c686b? >> >> There is no change in 'init' in this series, it is only QOM boilerplate >> code churn, no logical change intended. >> >>> Please also note that pegasos2 is not enabled by default due to >>> needing undistributable firmware ROM so to test it you need to enable it >>> in default-configs/devices/ppc-softmmu.mak >> >> I remember you said you were mostly interested in the VT8231, not >> the VT82C686. This series only QOM'ify the latter. > > OK as I said I haven't looked at it in detail. > >> What is your idea? Send the firmware off-list and explain how >> the OS works and how (what) to test? > > I've already sent you this info: > > https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg01553.html Well, if you have everything setup, it is easier to test and send a Tested-by tag. > but I can't write a test case so if you want to automate this and make > it part of QEMU tests then some help with that would be appreciated. You are not the only want wanting that. I'm working on a solution to run such tests (depending on binary blobs) in your own namespace, but it will take me time (doing it in my free time, without help). > As for the firmware, once Alexey's VOF (Virtual Open Firmware, minimial > OF emulation in QEMU) is merged I plan to try to use that to make it > possible to boot some guests with that so no firmware image would be > needed and pegasos2 could be enabled by default. But for now a firmware > image is needed as guests expect an OF environment to boot. > > Regards, > BALATON Zoltan
On Thu, 13 May 2021, Philippe Mathieu-Daudé wrote: > On 5/11/21 3:09 PM, BALATON Zoltan wrote: >> On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: >>> Hi Zoltan, >>> >>> On 5/11/21 1:28 PM, BALATON Zoltan wrote: >>>> On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: >>>>> The motivation behind this series is to remove the >>>>> isa_get_irq(NULL) call to simplify the ISA generic model. >>>>> >>>>> Since v1: >>>>> - rebased on top of remotes/dg-gitlab/tags/ppc-for-6.1-20210504 >>>> >>>> I'll try to have a look at these later but some notes: The pegasos2 >>>> changes are now in master so if this was before that maybe rebasing on >>>> master is now enough. >>> >>> This is what this series does, simply rebase on top of your merged >>> patches. >>> >>>> However I wonder if any changes to pegasos2.c is >>>> needed due to changed init of the chip model or is that only affecting >>>> 82c686b? >>> >>> There is no change in 'init' in this series, it is only QOM boilerplate >>> code churn, no logical change intended. >>> >>>> Please also note that pegasos2 is not enabled by default due to >>>> needing undistributable firmware ROM so to test it you need to enable it >>>> in default-configs/devices/ppc-softmmu.mak >>> >>> I remember you said you were mostly interested in the VT8231, not >>> the VT82C686. This series only QOM'ify the latter. >> >> OK as I said I haven't looked at it in detail. >> >>> What is your idea? Send the firmware off-list and explain how >>> the OS works and how (what) to test? >> >> I've already sent you this info: >> >> https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg01553.html > > Well, if you have everything setup, it is easier to test and send > a Tested-by tag. I indend to test it when I'll have some time but I could not get to it yet. >> but I can't write a test case so if you want to automate this and make >> it part of QEMU tests then some help with that would be appreciated. > > You are not the only want wanting that. I'm working on a solution to run > such tests (depending on binary blobs) in your own namespace, but it > will take me time (doing it in my free time, without help). I did not mean to say you should do this urgently, just sent this as a reminder about how this could be tested in case you forgot because you've asked about testing. Regards, BALATON Zoltan
On 5/13/21 1:54 PM, BALATON Zoltan wrote: > On Thu, 13 May 2021, Philippe Mathieu-Daudé wrote: >> On 5/11/21 3:09 PM, BALATON Zoltan wrote: >>> On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: >>>> Hi Zoltan, >>>> >>>> On 5/11/21 1:28 PM, BALATON Zoltan wrote: >>>>> On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: >>>>>> The motivation behind this series is to remove the >>>>>> isa_get_irq(NULL) call to simplify the ISA generic model. >>>>>> >>>>>> Since v1: >>>>>> - rebased on top of remotes/dg-gitlab/tags/ppc-for-6.1-20210504 >>>>> >>>>> I'll try to have a look at these later but some notes: The pegasos2 >>>>> changes are now in master so if this was before that maybe rebasing on >>>>> master is now enough. >>>> >>>> This is what this series does, simply rebase on top of your merged >>>> patches. >>>> >>>>> However I wonder if any changes to pegasos2.c is >>>>> needed due to changed init of the chip model or is that only affecting >>>>> 82c686b? >>>> >>>> There is no change in 'init' in this series, it is only QOM boilerplate >>>> code churn, no logical change intended. >>>> >>>>> Please also note that pegasos2 is not enabled by default due to >>>>> needing undistributable firmware ROM so to test it you need to >>>>> enable it >>>>> in default-configs/devices/ppc-softmmu.mak >>>> >>>> I remember you said you were mostly interested in the VT8231, not >>>> the VT82C686. This series only QOM'ify the latter. >>> >>> OK as I said I haven't looked at it in detail. >>> >>>> What is your idea? Send the firmware off-list and explain how >>>> the OS works and how (what) to test? >>> >>> I've already sent you this info: >>> >>> https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg01553.html >> >> Well, if you have everything setup, it is easier to test and send >> a Tested-by tag. > > I indend to test it when I'll have some time but I could not get to it yet. > >>> but I can't write a test case so if you want to automate this and make >>> it part of QEMU tests then some help with that would be appreciated. >> >> You are not the only want wanting that. I'm working on a solution to run >> such tests (depending on binary blobs) in your own namespace, but it >> will take me time (doing it in my free time, without help). > > I did not mean to say you should do this urgently, just sent this as a > reminder about how this could be tested in case you forgot because > you've asked about testing. Unrelated to this series, with master (dab59ce0312) I sometime get: Initializing KBD...00000012 FAILED. and then the mouse isn't working. Sometimes: Initializing KBD... Done. and the mouse is crazy (similar to my host mouse). Anyway, there is smth wrong with patch #2 of this series: "Simplify removing unuseful qemu_allocate_irqs() call".
On Thu, 13 May 2021, Philippe Mathieu-Daudé wrote: > On 5/13/21 1:54 PM, BALATON Zoltan wrote: >> On Thu, 13 May 2021, Philippe Mathieu-Daudé wrote: >>> On 5/11/21 3:09 PM, BALATON Zoltan wrote: >>>> On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: >>>>> Hi Zoltan, >>>>> >>>>> On 5/11/21 1:28 PM, BALATON Zoltan wrote: >>>>>> On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: >>>>>>> The motivation behind this series is to remove the >>>>>>> isa_get_irq(NULL) call to simplify the ISA generic model. >>>>>>> >>>>>>> Since v1: >>>>>>> - rebased on top of remotes/dg-gitlab/tags/ppc-for-6.1-20210504 >>>>>> >>>>>> I'll try to have a look at these later but some notes: The pegasos2 >>>>>> changes are now in master so if this was before that maybe rebasing on >>>>>> master is now enough. >>>>> >>>>> This is what this series does, simply rebase on top of your merged >>>>> patches. >>>>> >>>>>> However I wonder if any changes to pegasos2.c is >>>>>> needed due to changed init of the chip model or is that only affecting >>>>>> 82c686b? >>>>> >>>>> There is no change in 'init' in this series, it is only QOM boilerplate >>>>> code churn, no logical change intended. >>>>> >>>>>> Please also note that pegasos2 is not enabled by default due to >>>>>> needing undistributable firmware ROM so to test it you need to >>>>>> enable it >>>>>> in default-configs/devices/ppc-softmmu.mak >>>>> >>>>> I remember you said you were mostly interested in the VT8231, not >>>>> the VT82C686. This series only QOM'ify the latter. >>>> >>>> OK as I said I haven't looked at it in detail. >>>> >>>>> What is your idea? Send the firmware off-list and explain how >>>>> the OS works and how (what) to test? >>>> >>>> I've already sent you this info: >>>> >>>> https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg01553.html >>> >>> Well, if you have everything setup, it is easier to test and send >>> a Tested-by tag. >> >> I indend to test it when I'll have some time but I could not get to it yet. >> >>>> but I can't write a test case so if you want to automate this and make >>>> it part of QEMU tests then some help with that would be appreciated. >>> >>> You are not the only want wanting that. I'm working on a solution to run >>> such tests (depending on binary blobs) in your own namespace, but it >>> will take me time (doing it in my free time, without help). >> >> I did not mean to say you should do this urgently, just sent this as a >> reminder about how this could be tested in case you forgot because >> you've asked about testing. > > Unrelated to this series, with master (dab59ce0312) I sometime get: > > Initializing KBD...00000012 FAILED. > > and then the mouse isn't working. > > Sometimes: > > Initializing KBD... Done. > > and the mouse is crazy (similar to my host mouse). > > Anyway, there is smth wrong with patch #2 of this series: > "Simplify removing unuseful qemu_allocate_irqs() call". As I said before, when I've tried to do it that way first it did not work for me so I introduced the indirection which fixed it but I did not understand why it was needed or I forgot by now so all I remember is that I could not directly connect the irq and needed the local function for some reason. Regards, BALATON Zoltan
On 5/15/21 4:37 PM, BALATON Zoltan wrote: > On Thu, 13 May 2021, Philippe Mathieu-Daudé wrote: >> On 5/13/21 1:54 PM, BALATON Zoltan wrote: >>> On Thu, 13 May 2021, Philippe Mathieu-Daudé wrote: >>>> On 5/11/21 3:09 PM, BALATON Zoltan wrote: >>>>> On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: >>>>>> Hi Zoltan, >>>>>> >>>>>> On 5/11/21 1:28 PM, BALATON Zoltan wrote: >>>>>>> On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: >>>>>>>> The motivation behind this series is to remove the >>>>>>>> isa_get_irq(NULL) call to simplify the ISA generic model. >>>>>>>> >>>>>>>> Since v1: >>>>>>>> - rebased on top of remotes/dg-gitlab/tags/ppc-for-6.1-20210504 >>>>>>> >>>>>>> I'll try to have a look at these later but some notes: The pegasos2 >>>>>>> changes are now in master so if this was before that maybe >>>>>>> rebasing on >>>>>>> master is now enough. >>>>>> >>>>>> This is what this series does, simply rebase on top of your merged >>>>>> patches. >>>>>> >>>>>>> However I wonder if any changes to pegasos2.c is >>>>>>> needed due to changed init of the chip model or is that only >>>>>>> affecting >>>>>>> 82c686b? >>>>>> >>>>>> There is no change in 'init' in this series, it is only QOM >>>>>> boilerplate >>>>>> code churn, no logical change intended. >>>>>> >>>>>>> Please also note that pegasos2 is not enabled by default due to >>>>>>> needing undistributable firmware ROM so to test it you need to >>>>>>> enable it >>>>>>> in default-configs/devices/ppc-softmmu.mak >>>>>> >>>>>> I remember you said you were mostly interested in the VT8231, not >>>>>> the VT82C686. This series only QOM'ify the latter. >>>>> >>>>> OK as I said I haven't looked at it in detail. >>>>> >>>>>> What is your idea? Send the firmware off-list and explain how >>>>>> the OS works and how (what) to test? >>>>> >>>>> I've already sent you this info: >>>>> >>>>> https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg01553.html >>>> >>>> Well, if you have everything setup, it is easier to test and send >>>> a Tested-by tag. >>> >>> I indend to test it when I'll have some time but I could not get to >>> it yet. >>> >>>>> but I can't write a test case so if you want to automate this and make >>>>> it part of QEMU tests then some help with that would be appreciated. >>>> >>>> You are not the only want wanting that. I'm working on a solution to >>>> run >>>> such tests (depending on binary blobs) in your own namespace, but it >>>> will take me time (doing it in my free time, without help). >>> >>> I did not mean to say you should do this urgently, just sent this as a >>> reminder about how this could be tested in case you forgot because >>> you've asked about testing. >> >> Unrelated to this series, with master (dab59ce0312) I sometime get: >> >> Initializing KBD...00000012 FAILED. >> >> and then the mouse isn't working. >> >> Sometimes: >> >> Initializing KBD... Done. >> >> and the mouse is crazy (similar to my host mouse). >> >> Anyway, there is smth wrong with patch #2 of this series: >> "Simplify removing unuseful qemu_allocate_irqs() call". > > As I said before, when I've tried to do it that way first it did not > work for me so I introduced the indirection which fixed it but I did not > understand why it was needed or I forgot by now so all I remember is > that I could not directly connect the irq and needed the local function > for some reason. OK, I'll try to figure out what the problem is and come back to you. Regards, Phil.
On Sat, 15 May 2021, Philippe Mathieu-Daudé wrote: > On 5/15/21 4:37 PM, BALATON Zoltan wrote: >> On Thu, 13 May 2021, Philippe Mathieu-Daudé wrote: >>> On 5/13/21 1:54 PM, BALATON Zoltan wrote: >>>> On Thu, 13 May 2021, Philippe Mathieu-Daudé wrote: >>>>> On 5/11/21 3:09 PM, BALATON Zoltan wrote: >>>>>> On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: >>>>>>> Hi Zoltan, >>>>>>> >>>>>>> On 5/11/21 1:28 PM, BALATON Zoltan wrote: >>>>>>>> On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: >>>>>>>>> The motivation behind this series is to remove the >>>>>>>>> isa_get_irq(NULL) call to simplify the ISA generic model. >>>>>>>>> >>>>>>>>> Since v1: >>>>>>>>> - rebased on top of remotes/dg-gitlab/tags/ppc-for-6.1-20210504 >>>>>>>> >>>>>>>> I'll try to have a look at these later but some notes: The pegasos2 >>>>>>>> changes are now in master so if this was before that maybe >>>>>>>> rebasing on >>>>>>>> master is now enough. >>>>>>> >>>>>>> This is what this series does, simply rebase on top of your merged >>>>>>> patches. >>>>>>> >>>>>>>> However I wonder if any changes to pegasos2.c is >>>>>>>> needed due to changed init of the chip model or is that only >>>>>>>> affecting >>>>>>>> 82c686b? >>>>>>> >>>>>>> There is no change in 'init' in this series, it is only QOM >>>>>>> boilerplate >>>>>>> code churn, no logical change intended. >>>>>>> >>>>>>>> Please also note that pegasos2 is not enabled by default due to >>>>>>>> needing undistributable firmware ROM so to test it you need to >>>>>>>> enable it >>>>>>>> in default-configs/devices/ppc-softmmu.mak >>>>>>> >>>>>>> I remember you said you were mostly interested in the VT8231, not >>>>>>> the VT82C686. This series only QOM'ify the latter. >>>>>> >>>>>> OK as I said I haven't looked at it in detail. >>>>>> >>>>>>> What is your idea? Send the firmware off-list and explain how >>>>>>> the OS works and how (what) to test? >>>>>> >>>>>> I've already sent you this info: >>>>>> >>>>>> https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg01553.html >>>>> >>>>> Well, if you have everything setup, it is easier to test and send >>>>> a Tested-by tag. >>>> >>>> I indend to test it when I'll have some time but I could not get to >>>> it yet. >>>> >>>>>> but I can't write a test case so if you want to automate this and make >>>>>> it part of QEMU tests then some help with that would be appreciated. >>>>> >>>>> You are not the only want wanting that. I'm working on a solution to >>>>> run >>>>> such tests (depending on binary blobs) in your own namespace, but it >>>>> will take me time (doing it in my free time, without help). >>>> >>>> I did not mean to say you should do this urgently, just sent this as a >>>> reminder about how this could be tested in case you forgot because >>>> you've asked about testing. >>> >>> Unrelated to this series, with master (dab59ce0312) I sometime get: >>> >>> Initializing KBD...00000012 FAILED. >>> >>> and then the mouse isn't working. >>> >>> Sometimes: >>> >>> Initializing KBD... Done. >>> >>> and the mouse is crazy (similar to my host mouse). >>> >>> Anyway, there is smth wrong with patch #2 of this series: >>> "Simplify removing unuseful qemu_allocate_irqs() call". >> >> As I said before, when I've tried to do it that way first it did not >> work for me so I introduced the indirection which fixed it but I did not >> understand why it was needed or I forgot by now so all I remember is >> that I could not directly connect the irq and needed the local function >> for some reason. > > OK, I'll try to figure out what the problem is and come back to you. I'm not sure, but could this be related to a note Peter made in this series: https://lists.nongnu.org/archive/html/qemu-ppc/2020-12/msg00171.html about converting PPC interrupts to qdev qpios? Could it be that the irq cannot be connected directly as it has some unexpected behaviour due to this? Regards, BALATON Zoltan
© 2016 - 2024 Red Hat, Inc.