hw/i386/pc_piix.c | 34 ++++++++++++++++-- hw/i386/xen/xen-hvm.c | 9 +++-- hw/isa/piix.c | 66 +---------------------------------- include/hw/southbridge/piix.h | 1 - include/hw/xen/xen.h | 2 +- stubs/xen-hw-stub.c | 2 +- 6 files changed, 40 insertions(+), 74 deletions(-)
This series first renders TYPE_PIIX3_XEN_DEVICE redundant and finally removes
it. The motivation is to 1/ decouple PIIX from Xen and 2/ to make Xen in the PC
machine agnostic to the precise southbridge being used. 2/ will become
particularily interesting once PIIX4 becomes usable in the PC machine, avoiding
the "Frankenstein" use of PIIX4_ACPI in PIIX3.
Testing done:
None, because I don't know how to conduct this properly :(
Based-on: <20221221170003.2929-1-shentey@gmail.com>
"[PATCH v4 00/30] Consolidate PIIX south bridges"
Bernhard Beschow (6):
include/hw/xen/xen: Make xen_piix3_set_irq() generic and rename it
hw/isa/piix: Reuse piix3_realize() in piix3_xen_realize()
hw/isa/piix: Wire up Xen PCI IRQ handling outside of PIIX3
hw/isa/piix: Avoid Xen-specific variant of piix_write_config()
hw/isa/piix: Resolve redundant k->config_write assignments
hw/isa/piix: Resolve redundant TYPE_PIIX3_XEN_DEVICE
hw/i386/pc_piix.c | 34 ++++++++++++++++--
hw/i386/xen/xen-hvm.c | 9 +++--
hw/isa/piix.c | 66 +----------------------------------
include/hw/southbridge/piix.h | 1 -
include/hw/xen/xen.h | 2 +-
stubs/xen-hw-stub.c | 2 +-
6 files changed, 40 insertions(+), 74 deletions(-)
--
2.39.0
On 1/2/23 4:34 PM, Bernhard Beschow wrote: > This series first renders TYPE_PIIX3_XEN_DEVICE redundant and finally removes > it. The motivation is to 1/ decouple PIIX from Xen and 2/ to make Xen in the PC > machine agnostic to the precise southbridge being used. 2/ will become > particularily interesting once PIIX4 becomes usable in the PC machine, avoiding > the "Frankenstein" use of PIIX4_ACPI in PIIX3. > > Testing done: > None, because I don't know how to conduct this properly :( > > Based-on: <20221221170003.2929-1-shentey@gmail.com> > "[PATCH v4 00/30] Consolidate PIIX south bridges" > > Bernhard Beschow (6): > include/hw/xen/xen: Make xen_piix3_set_irq() generic and rename it > hw/isa/piix: Reuse piix3_realize() in piix3_xen_realize() > hw/isa/piix: Wire up Xen PCI IRQ handling outside of PIIX3 > hw/isa/piix: Avoid Xen-specific variant of piix_write_config() > hw/isa/piix: Resolve redundant k->config_write assignments > hw/isa/piix: Resolve redundant TYPE_PIIX3_XEN_DEVICE > > hw/i386/pc_piix.c | 34 ++++++++++++++++-- > hw/i386/xen/xen-hvm.c | 9 +++-- > hw/isa/piix.c | 66 +---------------------------------- This file does not exist on the Qemu master branch. But hw/isa/piix3.c and hw/isa/piix4.c do exist. I tried renaming it from piix.c to piix3.c in the patch, but the patch set still does not apply cleanly on my tree. Is this patch set re-based against something other than the current master Qemu branch? I have a system that is suitable for testing this patch set, but I need guidance on how to apply it to the Qemu source tree. Thanks, Chuck Zmudzinski > include/hw/southbridge/piix.h | 1 - > include/hw/xen/xen.h | 2 +- > stubs/xen-hw-stub.c | 2 +- > 6 files changed, 40 insertions(+), 74 deletions(-) >
Hi Chuck, On 3/1/23 04:15, Chuck Zmudzinski wrote: > On 1/2/23 4:34 PM, Bernhard Beschow wrote: >> This series first renders TYPE_PIIX3_XEN_DEVICE redundant and finally removes >> it. The motivation is to 1/ decouple PIIX from Xen and 2/ to make Xen in the PC >> machine agnostic to the precise southbridge being used. 2/ will become >> particularily interesting once PIIX4 becomes usable in the PC machine, avoiding >> the "Frankenstein" use of PIIX4_ACPI in PIIX3. >> >> Testing done: >> None, because I don't know how to conduct this properly :( >> >> Based-on: <20221221170003.2929-1-shentey@gmail.com> >> "[PATCH v4 00/30] Consolidate PIIX south bridges" This series is based on a previous series: https://lore.kernel.org/qemu-devel/20221221170003.2929-1-shentey@gmail.com/ (which itself also is). >> Bernhard Beschow (6): >> include/hw/xen/xen: Make xen_piix3_set_irq() generic and rename it >> hw/isa/piix: Reuse piix3_realize() in piix3_xen_realize() >> hw/isa/piix: Wire up Xen PCI IRQ handling outside of PIIX3 >> hw/isa/piix: Avoid Xen-specific variant of piix_write_config() >> hw/isa/piix: Resolve redundant k->config_write assignments >> hw/isa/piix: Resolve redundant TYPE_PIIX3_XEN_DEVICE >> >> hw/i386/pc_piix.c | 34 ++++++++++++++++-- >> hw/i386/xen/xen-hvm.c | 9 +++-- >> hw/isa/piix.c | 66 +---------------------------------- > > This file does not exist on the Qemu master branch. > But hw/isa/piix3.c and hw/isa/piix4.c do exist. > > I tried renaming it from piix.c to piix3.c in the patch, but > the patch set still does not apply cleanly on my tree. > > Is this patch set re-based against something other than > the current master Qemu branch? > > I have a system that is suitable for testing this patch set, but > I need guidance on how to apply it to the Qemu source tree. You can ask Bernhard to publish a branch with the full work, or apply each series locally. I use the b4 tool for that: https://b4.docs.kernel.org/en/latest/installing.html i.e.: $ git checkout -b shentey_work $ b4 am 20221120150550.63059-1-shentey@gmail.com $ git am ./v2_20221120_shentey_decouple_intx_to_lnkx_routing_from_south_bridges.mbx $ b4 am 20221221170003.2929-1-shentey@gmail.com $ git am ./v4_20221221_shentey_this_series_consolidates_the_implementations_of_the_piix3_and_piix4_south.mbx $ b4 am 20230102213504.14646-1-shentey@gmail.com $ git am ./20230102_shentey_resolve_type_piix3_xen_device.mbx Now the branch 'shentey_work' contains all the patches and you can test. Regards, Phil.
On Tue, Jan 3, 2023 at 2:17 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote: > Hi Chuck, > > On 3/1/23 04:15, Chuck Zmudzinski wrote: > > On 1/2/23 4:34 PM, Bernhard Beschow wrote: > >> This series first renders TYPE_PIIX3_XEN_DEVICE redundant and finally > removes > >> it. The motivation is to 1/ decouple PIIX from Xen and 2/ to make Xen > in the PC > >> machine agnostic to the precise southbridge being used. 2/ will become > >> particularily interesting once PIIX4 becomes usable in the PC machine, > avoiding > >> the "Frankenstein" use of PIIX4_ACPI in PIIX3. > >> > >> Testing done: > >> None, because I don't know how to conduct this properly :( > >> > >> Based-on: <20221221170003.2929-1-shentey@gmail.com> > >> "[PATCH v4 00/30] Consolidate PIIX south bridges" > > This series is based on a previous series: > https://lore.kernel.org/qemu-devel/20221221170003.2929-1-shentey@gmail.com/ > (which itself also is). > > >> Bernhard Beschow (6): > >> include/hw/xen/xen: Make xen_piix3_set_irq() generic and rename it > >> hw/isa/piix: Reuse piix3_realize() in piix3_xen_realize() > >> hw/isa/piix: Wire up Xen PCI IRQ handling outside of PIIX3 > >> hw/isa/piix: Avoid Xen-specific variant of piix_write_config() > >> hw/isa/piix: Resolve redundant k->config_write assignments > >> hw/isa/piix: Resolve redundant TYPE_PIIX3_XEN_DEVICE > >> > >> hw/i386/pc_piix.c | 34 ++++++++++++++++-- > >> hw/i386/xen/xen-hvm.c | 9 +++-- > >> hw/isa/piix.c | 66 +---------------------------------- > > > > This file does not exist on the Qemu master branch. > > But hw/isa/piix3.c and hw/isa/piix4.c do exist. > > > > I tried renaming it from piix.c to piix3.c in the patch, but > > the patch set still does not apply cleanly on my tree. > > > > Is this patch set re-based against something other than > > the current master Qemu branch? > > > > I have a system that is suitable for testing this patch set, but > > I need guidance on how to apply it to the Qemu source tree. > > You can ask Bernhard to publish a branch with the full work, > Hi Chuck, ... or just visit https://patchew.org/QEMU/20230102213504.14646-1-shentey@gmail.com/ . There you'll find a git tag with a complete history and all instructions! Thanks for giving my series a test ride! Best regards, Bernhard or apply each series locally. I use the b4 tool for that: > https://b4.docs.kernel.org/en/latest/installing.html > > i.e.: > > $ git checkout -b shentey_work > $ b4 am 20221120150550.63059-1-shentey@gmail.com > $ git am > ./v2_20221120_shentey_decouple_intx_to_lnkx_routing_from_south_bridges.mbx > $ b4 am 20221221170003.2929-1-shentey@gmail.com > $ git am > > ./v4_20221221_shentey_this_series_consolidates_the_implementations_of_the_piix3_and_piix4_south.mbx > $ b4 am 20230102213504.14646-1-shentey@gmail.com > $ git am ./20230102_shentey_resolve_type_piix3_xen_device.mbx > > Now the branch 'shentey_work' contains all the patches and you can test. > > Regards, > > Phil. >
On 1/3/2023 8:38 AM, Bernhard Beschow wrote: > > > On Tue, Jan 3, 2023 at 2:17 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote: > > Hi Chuck, > > On 3/1/23 04:15, Chuck Zmudzinski wrote: > > On 1/2/23 4:34 PM, Bernhard Beschow wrote: > >> This series first renders TYPE_PIIX3_XEN_DEVICE redundant and finally removes > >> it. The motivation is to 1/ decouple PIIX from Xen and 2/ to make Xen in the PC > >> machine agnostic to the precise southbridge being used. 2/ will become > >> particularily interesting once PIIX4 becomes usable in the PC machine, avoiding > >> the "Frankenstein" use of PIIX4_ACPI in PIIX3. > >> > >> Testing done: > >> None, because I don't know how to conduct this properly :( > >> > >> Based-on: <20221221170003.2929-1-shentey@gmail.com> > >> "[PATCH v4 00/30] Consolidate PIIX south bridges" > > This series is based on a previous series: > https://lore.kernel.org/qemu-devel/20221221170003.2929-1-shentey@gmail.com/ > (which itself also is). > > >> Bernhard Beschow (6): > >> include/hw/xen/xen: Make xen_piix3_set_irq() generic and rename it > >> hw/isa/piix: Reuse piix3_realize() in piix3_xen_realize() > >> hw/isa/piix: Wire up Xen PCI IRQ handling outside of PIIX3 > >> hw/isa/piix: Avoid Xen-specific variant of piix_write_config() > >> hw/isa/piix: Resolve redundant k->config_write assignments > >> hw/isa/piix: Resolve redundant TYPE_PIIX3_XEN_DEVICE > >> > >> hw/i386/pc_piix.c | 34 ++++++++++++++++-- > >> hw/i386/xen/xen-hvm.c | 9 +++-- > >> hw/isa/piix.c | 66 +---------------------------------- > > > > This file does not exist on the Qemu master branch. > > But hw/isa/piix3.c and hw/isa/piix4.c do exist. > > > > I tried renaming it from piix.c to piix3.c in the patch, but > > the patch set still does not apply cleanly on my tree. > > > > Is this patch set re-based against something other than > > the current master Qemu branch? > > > > I have a system that is suitable for testing this patch set, but > > I need guidance on how to apply it to the Qemu source tree. > > You can ask Bernhard to publish a branch with the full work, > > > Hi Chuck, > > ... or just visit https://patchew.org/QEMU/20230102213504.14646-1-shentey@gmail.com/ . There you'll find a git tag with a complete history and all instructions! > > Thanks for giving my series a test ride! > > Best regards, > Bernhard > > or apply each series locally. I use the b4 tool for that: > https://b4.docs.kernel.org/en/latest/installing.html > > i.e.: > > $ git checkout -b shentey_work > $ b4 am 20221120150550.63059-1-shentey@gmail.com > $ git am > ./v2_20221120_shentey_decouple_intx_to_lnkx_routing_from_south_bridges.mbx > $ b4 am 20221221170003.2929-1-shentey@gmail.com > $ git am > ./v4_20221221_shentey_this_series_consolidates_the_implementations_of_the_piix3_and_piix4_south.mbx > $ b4 am 20230102213504.14646-1-shentey@gmail.com > $ git am ./20230102_shentey_resolve_type_piix3_xen_device.mbx > > Now the branch 'shentey_work' contains all the patches and you can test. > > Regards, > > Phil. > Hi Phil and Bernard, I tried applying these 3 patch series on top of the current qemu master branch. Unfortunately, I saw a regression, so I can't give a tested-by tag yet. Here are the details of the testing I did so far: Xen only needs one target, the i386-softmmu target which creates the qemu-system-i386 binary that Xen uses for its device model. That target compiled and linked with no problems with these 3 patch series applied on top of qemu master. I didn't try building any other targets. My tests used the xenfv machine type with the xen platform pci device, which is ordinarily called a xen hvm guest with xen paravirtualized network and block device drivers. It is based on the i440fx machine type and so emulates piix3. I tested the xen hvm guests with two different configurations as described below. I tested both Linux and Windows guests, with mixed results. With the current Qemu master (commit 222059a0fccf4 without the 3 patch series applied), all tested guest configurations work normally for both Linux and Windows guests. With these 3 patch series applied on top of the qemu master branch, which tries to consolidate piix3 and piix4 and resolve the xen piix3 device that my guests use, I unfortunately got a regression. The regression occurred with a configuration that uses the qemu bochs stdvga graphics device with a vnc display, and the qemu usb-tablet device to emulate the mouse and keyboard. After applying the 3 patch series, the emulated mouse is not working at all for Linux guests. It works for Windows guests, but the mouse pointer in the guest does not follow the mouse pointer in the vnc window as closely as it does without the 3 patch series. So this is the bad news of a regression introduced somewhere in these 3 patch series. The good news is that by using guests in a configuration that does not use the qemu usb-tablet device or the bochs stdvga device but instead uses a real passed through usb3 controller with a real usb mouse and a real usb keyboard connected, and also the real sound card and vga device passed through and a 1920x1080 HDMI monitor, there is no regression introduced by the 3 patch series and both Linux and Windows guests in that configuration work perfectly. My next test will be to test Bernhard's published git tag without trying to merge the 3 patch series into master and see if that also has the regression. I also will double check that I didn't make any mistakes in merging the 3 patch series by creating the shentey_work branch with b4 and git as Phil described and compare that to my working tree. I also will try testing only the first series, then the first series and the second series, to try to determine in which of the 3 series the regression is introduced. Best regards, Chuck
Am 4. Januar 2023 08:18:59 UTC schrieb Chuck Zmudzinski <brchuckz@aol.com>: >On 1/3/2023 8:38 AM, Bernhard Beschow wrote: >> >> >> On Tue, Jan 3, 2023 at 2:17 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote: >> >> Hi Chuck, >> >> On 3/1/23 04:15, Chuck Zmudzinski wrote: >> > On 1/2/23 4:34 PM, Bernhard Beschow wrote: >> >> This series first renders TYPE_PIIX3_XEN_DEVICE redundant and finally removes >> >> it. The motivation is to 1/ decouple PIIX from Xen and 2/ to make Xen in the PC >> >> machine agnostic to the precise southbridge being used. 2/ will become >> >> particularily interesting once PIIX4 becomes usable in the PC machine, avoiding >> >> the "Frankenstein" use of PIIX4_ACPI in PIIX3. >> >> >> >> Testing done: >> >> None, because I don't know how to conduct this properly :( >> >> >> >> Based-on: <20221221170003.2929-1-shentey@gmail.com> >> >> "[PATCH v4 00/30] Consolidate PIIX south bridges" >> >> This series is based on a previous series: >> https://lore.kernel.org/qemu-devel/20221221170003.2929-1-shentey@gmail.com/ >> (which itself also is). >> >> >> Bernhard Beschow (6): >> >> include/hw/xen/xen: Make xen_piix3_set_irq() generic and rename it >> >> hw/isa/piix: Reuse piix3_realize() in piix3_xen_realize() >> >> hw/isa/piix: Wire up Xen PCI IRQ handling outside of PIIX3 >> >> hw/isa/piix: Avoid Xen-specific variant of piix_write_config() >> >> hw/isa/piix: Resolve redundant k->config_write assignments >> >> hw/isa/piix: Resolve redundant TYPE_PIIX3_XEN_DEVICE >> >> >> >> hw/i386/pc_piix.c | 34 ++++++++++++++++-- >> >> hw/i386/xen/xen-hvm.c | 9 +++-- >> >> hw/isa/piix.c | 66 +---------------------------------- >> > >> > This file does not exist on the Qemu master branch. >> > But hw/isa/piix3.c and hw/isa/piix4.c do exist. >> > >> > I tried renaming it from piix.c to piix3.c in the patch, but >> > the patch set still does not apply cleanly on my tree. >> > >> > Is this patch set re-based against something other than >> > the current master Qemu branch? >> > >> > I have a system that is suitable for testing this patch set, but >> > I need guidance on how to apply it to the Qemu source tree. >> >> You can ask Bernhard to publish a branch with the full work, >> >> >> Hi Chuck, >> >> ... or just visit https://patchew.org/QEMU/20230102213504.14646-1-shentey@gmail.com/ . There you'll find a git tag with a complete history and all instructions! >> >> Thanks for giving my series a test ride! >> >> Best regards, >> Bernhard >> >> or apply each series locally. I use the b4 tool for that: >> https://b4.docs.kernel.org/en/latest/installing.html >> >> i.e.: >> >> $ git checkout -b shentey_work >> $ b4 am 20221120150550.63059-1-shentey@gmail.com >> $ git am >> ./v2_20221120_shentey_decouple_intx_to_lnkx_routing_from_south_bridges.mbx >> $ b4 am 20221221170003.2929-1-shentey@gmail.com >> $ git am >> ./v4_20221221_shentey_this_series_consolidates_the_implementations_of_the_piix3_and_piix4_south.mbx >> $ b4 am 20230102213504.14646-1-shentey@gmail.com >> $ git am ./20230102_shentey_resolve_type_piix3_xen_device.mbx >> >> Now the branch 'shentey_work' contains all the patches and you can test. >> >> Regards, >> >> Phil. >> > >Hi Phil and Bernard, > >I tried applying these 3 patch series on top of the current qemu >master branch. > >Unfortunately, I saw a regression, so I can't give a tested-by tag yet. Hi Chuck, Thanks for your valuable test report! I think the culprit may be commit https://lists.nongnu.org/archive/html/qemu-devel/2023-01/msg00102.html where now 128 PIRQs are considered rather than four. I'll revisit my series and will prepare a v2 in the next days. I think there is no need for further testing v1. Thanks, Bernhard > >Here are the details of the testing I did so far: > >Xen only needs one target, the i386-softmmu target which creates >the qemu-system-i386 binary that Xen uses for its device model. >That target compiled and linked with no problems with these 3 >patch series applied on top of qemu master. I didn't try building >any other targets. > >My tests used the xenfv machine type with the xen platform >pci device, which is ordinarily called a xen hvm guest with xen >paravirtualized network and block device drivers. It is based on the >i440fx machine type and so emulates piix3. I tested the xen >hvm guests with two different configurations as described below. > >I tested both Linux and Windows guests, with mixed results. With the >current Qemu master (commit 222059a0fccf4 without the 3 patch >series applied), all tested guest configurations work normally for both >Linux and Windows guests. > >With these 3 patch series applied on top of the qemu master branch, >which tries to consolidate piix3 and piix4 and resolve the xen piix3 >device that my guests use, I unfortunately got a regression. > >The regression occurred with a configuration that uses the qemu >bochs stdvga graphics device with a vnc display, and the qemu >usb-tablet device to emulate the mouse and keyboard. After applying >the 3 patch series, the emulated mouse is not working at all for Linux >guests. It works for Windows guests, but the mouse pointer in the >guest does not follow the mouse pointer in the vnc window as closely >as it does without the 3 patch series. So this is the bad news of a >regression introduced somewhere in these 3 patch series. > >The good news is that by using guests in a configuration that does >not use the qemu usb-tablet device or the bochs stdvga device but >instead uses a real passed through usb3 controller with a real usb >mouse and a real usb keyboard connected, and also the real sound >card and vga device passed through and a 1920x1080 HDMI monitor, >there is no regression introduced by the 3 patch series and both Linux >and Windows guests in that configuration work perfectly. > >My next test will be to test Bernhard's published git tag without >trying to merge the 3 patch series into master and see if that also >has the regression. I also will double check that I didn't make >any mistakes in merging the 3 patch series by creating the shentey_work >branch with b4 and git as Phil described and compare that to my >working tree. > >I also will try testing only the first series, then the first series and the >second series, to try to determine in which of the 3 series the regression >is introduced. > >Best regards, > >Chuck
On 1/4/2023 7:13 AM, Bernhard Beschow wrote: > Am 4. Januar 2023 08:18:59 UTC schrieb Chuck Zmudzinski <brchuckz@aol.com>: > >On 1/3/2023 8:38 AM, Bernhard Beschow wrote: > >> > >> > >> On Tue, Jan 3, 2023 at 2:17 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote: > >> > >> Hi Chuck, > >> > >> On 3/1/23 04:15, Chuck Zmudzinski wrote: > >> > On 1/2/23 4:34 PM, Bernhard Beschow wrote: > >> >> This series first renders TYPE_PIIX3_XEN_DEVICE redundant and finally removes > >> >> it. The motivation is to 1/ decouple PIIX from Xen and 2/ to make Xen in the PC > >> >> machine agnostic to the precise southbridge being used. 2/ will become > >> >> particularily interesting once PIIX4 becomes usable in the PC machine, avoiding > >> >> the "Frankenstein" use of PIIX4_ACPI in PIIX3. > >> >> > >> >> Testing done: > >> >> None, because I don't know how to conduct this properly :( > >> >> > >> >> Based-on: <20221221170003.2929-1-shentey@gmail.com> > >> >> "[PATCH v4 00/30] Consolidate PIIX south bridges" > >> > >> This series is based on a previous series: > >> https://lore.kernel.org/qemu-devel/20221221170003.2929-1-shentey@gmail.com/ > >> (which itself also is). > >> > >> >> Bernhard Beschow (6): > >> >> include/hw/xen/xen: Make xen_piix3_set_irq() generic and rename it > >> >> hw/isa/piix: Reuse piix3_realize() in piix3_xen_realize() > >> >> hw/isa/piix: Wire up Xen PCI IRQ handling outside of PIIX3 > >> >> hw/isa/piix: Avoid Xen-specific variant of piix_write_config() > >> >> hw/isa/piix: Resolve redundant k->config_write assignments > >> >> hw/isa/piix: Resolve redundant TYPE_PIIX3_XEN_DEVICE > >> >> > >> >> hw/i386/pc_piix.c | 34 ++++++++++++++++-- > >> >> hw/i386/xen/xen-hvm.c | 9 +++-- > >> >> hw/isa/piix.c | 66 +---------------------------------- > >> > > >> > This file does not exist on the Qemu master branch. > >> > But hw/isa/piix3.c and hw/isa/piix4.c do exist. > >> > > >> > I tried renaming it from piix.c to piix3.c in the patch, but > >> > the patch set still does not apply cleanly on my tree. > >> > > >> > Is this patch set re-based against something other than > >> > the current master Qemu branch? > >> > > >> > I have a system that is suitable for testing this patch set, but > >> > I need guidance on how to apply it to the Qemu source tree. > >> > >> You can ask Bernhard to publish a branch with the full work, > >> > >> > >> Hi Chuck, > >> > >> ... or just visit https://patchew.org/QEMU/20230102213504.14646-1-shentey@gmail.com/ . There you'll find a git tag with a complete history and all instructions! > >> > >> Thanks for giving my series a test ride! > >> > >> Best regards, > >> Bernhard > >> > >> or apply each series locally. I use the b4 tool for that: > >> https://b4.docs.kernel.org/en/latest/installing.html > >> > >> i.e.: > >> > >> $ git checkout -b shentey_work > >> $ b4 am 20221120150550.63059-1-shentey@gmail.com > >> $ git am > >> ./v2_20221120_shentey_decouple_intx_to_lnkx_routing_from_south_bridges.mbx > >> $ b4 am 20221221170003.2929-1-shentey@gmail.com > >> $ git am > >> ./v4_20221221_shentey_this_series_consolidates_the_implementations_of_the_piix3_and_piix4_south.mbx > >> $ b4 am 20230102213504.14646-1-shentey@gmail.com > >> $ git am ./20230102_shentey_resolve_type_piix3_xen_device.mbx > >> > >> Now the branch 'shentey_work' contains all the patches and you can test. > >> > >> Regards, > >> > >> Phil. > >> > > > >Hi Phil and Bernard, > > > >I tried applying these 3 patch series on top of the current qemu > >master branch. > > > >Unfortunately, I saw a regression, so I can't give a tested-by tag yet. > > Hi Chuck, > > Thanks for your valuable test report! I think the culprit may be commit https://lists.nongnu.org/archive/html/qemu-devel/2023-01/msg00102.html where now 128 PIRQs are considered rather than four. I'll revisit my series and will prepare a v2 in the next days. I think there is no need for further testing v1. > > Thanks, > Bernhard Hi Bernhard, Thanks for letting me know I do not need to test v1 further. I agree the symptoms are that it is an IRQ problem - it looks like IRQs associated with the emulated usb tablet device are not making it to the guest with the patched v1 piix device on xen. I will be looking for your v2 in coming days and try it out also! Best regards, Chuck > > > > >Here are the details of the testing I did so far: > > > >Xen only needs one target, the i386-softmmu target which creates > >the qemu-system-i386 binary that Xen uses for its device model. > >That target compiled and linked with no problems with these 3 > >patch series applied on top of qemu master. I didn't try building > >any other targets. > > > >My tests used the xenfv machine type with the xen platform > >pci device, which is ordinarily called a xen hvm guest with xen > >paravirtualized network and block device drivers. It is based on the > >i440fx machine type and so emulates piix3. I tested the xen > >hvm guests with two different configurations as described below. > > > >I tested both Linux and Windows guests, with mixed results. With the > >current Qemu master (commit 222059a0fccf4 without the 3 patch > >series applied), all tested guest configurations work normally for both > >Linux and Windows guests. > > > >With these 3 patch series applied on top of the qemu master branch, > >which tries to consolidate piix3 and piix4 and resolve the xen piix3 > >device that my guests use, I unfortunately got a regression. > > > >The regression occurred with a configuration that uses the qemu > >bochs stdvga graphics device with a vnc display, and the qemu > >usb-tablet device to emulate the mouse and keyboard. After applying > >the 3 patch series, the emulated mouse is not working at all for Linux > >guests. It works for Windows guests, but the mouse pointer in the > >guest does not follow the mouse pointer in the vnc window as closely > >as it does without the 3 patch series. So this is the bad news of a > >regression introduced somewhere in these 3 patch series. > > > >The good news is that by using guests in a configuration that does > >not use the qemu usb-tablet device or the bochs stdvga device but > >instead uses a real passed through usb3 controller with a real usb > >mouse and a real usb keyboard connected, and also the real sound > >card and vga device passed through and a 1920x1080 HDMI monitor, > >there is no regression introduced by the 3 patch series and both Linux > >and Windows guests in that configuration work perfectly. > > > >My next test will be to test Bernhard's published git tag without > >trying to merge the 3 patch series into master and see if that also > >has the regression. I also will double check that I didn't make > >any mistakes in merging the 3 patch series by creating the shentey_work > >branch with b4 and git as Phil described and compare that to my > >working tree. > > > >I also will try testing only the first series, then the first series and the > >second series, to try to determine in which of the 3 series the regression > >is introduced. > > > >Best regards, > > > >Chuck
Am 4. Januar 2023 13:11:16 UTC schrieb Chuck Zmudzinski <brchuckz@aol.com>: >On 1/4/2023 7:13 AM, Bernhard Beschow wrote: >> Am 4. Januar 2023 08:18:59 UTC schrieb Chuck Zmudzinski <brchuckz@aol.com>: >> >On 1/3/2023 8:38 AM, Bernhard Beschow wrote: >> >> >> >> >> >> On Tue, Jan 3, 2023 at 2:17 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote: >> >> >> >> Hi Chuck, >> >> >> >> On 3/1/23 04:15, Chuck Zmudzinski wrote: >> >> > On 1/2/23 4:34 PM, Bernhard Beschow wrote: >> >> >> This series first renders TYPE_PIIX3_XEN_DEVICE redundant and finally removes >> >> >> it. The motivation is to 1/ decouple PIIX from Xen and 2/ to make Xen in the PC >> >> >> machine agnostic to the precise southbridge being used. 2/ will become >> >> >> particularily interesting once PIIX4 becomes usable in the PC machine, avoiding >> >> >> the "Frankenstein" use of PIIX4_ACPI in PIIX3. >> >> >> >> >> >> Testing done: >> >> >> None, because I don't know how to conduct this properly :( >> >> >> >> >> >> Based-on: <20221221170003.2929-1-shentey@gmail.com> >> >> >> "[PATCH v4 00/30] Consolidate PIIX south bridges" >> >> >> >> This series is based on a previous series: >> >> https://lore.kernel.org/qemu-devel/20221221170003.2929-1-shentey@gmail.com/ >> >> (which itself also is). >> >> >> >> >> Bernhard Beschow (6): >> >> >> include/hw/xen/xen: Make xen_piix3_set_irq() generic and rename it >> >> >> hw/isa/piix: Reuse piix3_realize() in piix3_xen_realize() >> >> >> hw/isa/piix: Wire up Xen PCI IRQ handling outside of PIIX3 >> >> >> hw/isa/piix: Avoid Xen-specific variant of piix_write_config() >> >> >> hw/isa/piix: Resolve redundant k->config_write assignments >> >> >> hw/isa/piix: Resolve redundant TYPE_PIIX3_XEN_DEVICE >> >> >> >> >> >> hw/i386/pc_piix.c | 34 ++++++++++++++++-- >> >> >> hw/i386/xen/xen-hvm.c | 9 +++-- >> >> >> hw/isa/piix.c | 66 +---------------------------------- >> >> > >> >> > This file does not exist on the Qemu master branch. >> >> > But hw/isa/piix3.c and hw/isa/piix4.c do exist. >> >> > >> >> > I tried renaming it from piix.c to piix3.c in the patch, but >> >> > the patch set still does not apply cleanly on my tree. >> >> > >> >> > Is this patch set re-based against something other than >> >> > the current master Qemu branch? >> >> > >> >> > I have a system that is suitable for testing this patch set, but >> >> > I need guidance on how to apply it to the Qemu source tree. >> >> >> >> You can ask Bernhard to publish a branch with the full work, >> >> >> >> >> >> Hi Chuck, >> >> >> >> ... or just visit https://patchew.org/QEMU/20230102213504.14646-1-shentey@gmail.com/ . There you'll find a git tag with a complete history and all instructions! >> >> >> >> Thanks for giving my series a test ride! >> >> >> >> Best regards, >> >> Bernhard >> >> >> >> or apply each series locally. I use the b4 tool for that: >> >> https://b4.docs.kernel.org/en/latest/installing.html >> >> >> >> i.e.: >> >> >> >> $ git checkout -b shentey_work >> >> $ b4 am 20221120150550.63059-1-shentey@gmail.com >> >> $ git am >> >> ./v2_20221120_shentey_decouple_intx_to_lnkx_routing_from_south_bridges.mbx >> >> $ b4 am 20221221170003.2929-1-shentey@gmail.com >> >> $ git am >> >> ./v4_20221221_shentey_this_series_consolidates_the_implementations_of_the_piix3_and_piix4_south.mbx >> >> $ b4 am 20230102213504.14646-1-shentey@gmail.com >> >> $ git am ./20230102_shentey_resolve_type_piix3_xen_device.mbx >> >> >> >> Now the branch 'shentey_work' contains all the patches and you can test. >> >> >> >> Regards, >> >> >> >> Phil. >> >> >> > >> >Hi Phil and Bernard, >> > >> >I tried applying these 3 patch series on top of the current qemu >> >master branch. >> > >> >Unfortunately, I saw a regression, so I can't give a tested-by tag yet. >> >> Hi Chuck, >> >> Thanks for your valuable test report! I think the culprit may be commit https://lists.nongnu.org/archive/html/qemu-devel/2023-01/msg00102.html where now 128 PIRQs are considered rather than four. I'll revisit my series and will prepare a v2 in the next days. I think there is no need for further testing v1. >> >> Thanks, >> Bernhard > >Hi Bernhard, > >Thanks for letting me know I do not need to test v1 further. I agree the >symptoms are that it is an IRQ problem - it looks like IRQs associated with >the emulated usb tablet device are not making it to the guest with the >patched v1 piix device on xen. All PCI IRQs were routed to PCI slot 0. This should be fixed in v2 now. >I will be looking for your v2 in coming days and try it out also! Thank you! Here it is: https://patchew.org/QEMU/20230104144437.27479-1-shentey@gmail.com/ Best regards, Bernhard > >Best regards, > >Chuck > >> >> > >> >Here are the details of the testing I did so far: >> > >> >Xen only needs one target, the i386-softmmu target which creates >> >the qemu-system-i386 binary that Xen uses for its device model. >> >That target compiled and linked with no problems with these 3 >> >patch series applied on top of qemu master. I didn't try building >> >any other targets. >> > >> >My tests used the xenfv machine type with the xen platform >> >pci device, which is ordinarily called a xen hvm guest with xen >> >paravirtualized network and block device drivers. It is based on the >> >i440fx machine type and so emulates piix3. I tested the xen >> >hvm guests with two different configurations as described below. >> > >> >I tested both Linux and Windows guests, with mixed results. With the >> >current Qemu master (commit 222059a0fccf4 without the 3 patch >> >series applied), all tested guest configurations work normally for both >> >Linux and Windows guests. >> > >> >With these 3 patch series applied on top of the qemu master branch, >> >which tries to consolidate piix3 and piix4 and resolve the xen piix3 >> >device that my guests use, I unfortunately got a regression. >> > >> >The regression occurred with a configuration that uses the qemu >> >bochs stdvga graphics device with a vnc display, and the qemu >> >usb-tablet device to emulate the mouse and keyboard. After applying >> >the 3 patch series, the emulated mouse is not working at all for Linux >> >guests. It works for Windows guests, but the mouse pointer in the >> >guest does not follow the mouse pointer in the vnc window as closely >> >as it does without the 3 patch series. So this is the bad news of a >> >regression introduced somewhere in these 3 patch series. >> > >> >The good news is that by using guests in a configuration that does >> >not use the qemu usb-tablet device or the bochs stdvga device but >> >instead uses a real passed through usb3 controller with a real usb >> >mouse and a real usb keyboard connected, and also the real sound >> >card and vga device passed through and a 1920x1080 HDMI monitor, >> >there is no regression introduced by the 3 patch series and both Linux >> >and Windows guests in that configuration work perfectly. >> > >> >My next test will be to test Bernhard's published git tag without >> >trying to merge the 3 patch series into master and see if that also >> >has the regression. I also will double check that I didn't make >> >any mistakes in merging the 3 patch series by creating the shentey_work >> >branch with b4 and git as Phil described and compare that to my >> >working tree. >> > >> >I also will try testing only the first series, then the first series and the >> >second series, to try to determine in which of the 3 series the regression >> >is introduced. >> > >> >Best regards, >> > >> >Chuck >
On 1/4/23 11:12 AM, Bernhard Beschow wrote: > > > Am 4. Januar 2023 13:11:16 UTC schrieb Chuck Zmudzinski <brchuckz@aol.com>: >>On 1/4/2023 7:13 AM, Bernhard Beschow wrote: >>> Am 4. Januar 2023 08:18:59 UTC schrieb Chuck Zmudzinski <brchuckz@aol.com>: >>> >On 1/3/2023 8:38 AM, Bernhard Beschow wrote: >>> >> >>> >> >>> >> On Tue, Jan 3, 2023 at 2:17 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote: >>> >> >>> >> Hi Chuck, >>> >> >>> >> On 3/1/23 04:15, Chuck Zmudzinski wrote: >>> >> > On 1/2/23 4:34 PM, Bernhard Beschow wrote: >>> >> >> This series first renders TYPE_PIIX3_XEN_DEVICE redundant and finally removes >>> >> >> it. The motivation is to 1/ decouple PIIX from Xen and 2/ to make Xen in the PC >>> >> >> machine agnostic to the precise southbridge being used. 2/ will become >>> >> >> particularily interesting once PIIX4 becomes usable in the PC machine, avoiding >>> >> >> the "Frankenstein" use of PIIX4_ACPI in PIIX3. >>> >> >> >>> >> >> Testing done: >>> >> >> None, because I don't know how to conduct this properly :( >>> >> >> >>> >> >> Based-on: <20221221170003.2929-1-shentey@gmail.com> >>> >> >> "[PATCH v4 00/30] Consolidate PIIX south bridges" >>> >> >>> >> This series is based on a previous series: >>> >> https://lore.kernel.org/qemu-devel/20221221170003.2929-1-shentey@gmail.com/ >>> >> (which itself also is). >>> >> >>> >> >> Bernhard Beschow (6): >>> >> >> include/hw/xen/xen: Make xen_piix3_set_irq() generic and rename it >>> >> >> hw/isa/piix: Reuse piix3_realize() in piix3_xen_realize() >>> >> >> hw/isa/piix: Wire up Xen PCI IRQ handling outside of PIIX3 >>> >> >> hw/isa/piix: Avoid Xen-specific variant of piix_write_config() >>> >> >> hw/isa/piix: Resolve redundant k->config_write assignments >>> >> >> hw/isa/piix: Resolve redundant TYPE_PIIX3_XEN_DEVICE >>> >> >> >>> >> >> hw/i386/pc_piix.c | 34 ++++++++++++++++-- >>> >> >> hw/i386/xen/xen-hvm.c | 9 +++-- >>> >> >> hw/isa/piix.c | 66 +---------------------------------- >>> >> > >>> >> > This file does not exist on the Qemu master branch. >>> >> > But hw/isa/piix3.c and hw/isa/piix4.c do exist. >>> >> > >>> >> > I tried renaming it from piix.c to piix3.c in the patch, but >>> >> > the patch set still does not apply cleanly on my tree. >>> >> > >>> >> > Is this patch set re-based against something other than >>> >> > the current master Qemu branch? >>> >> > >>> >> > I have a system that is suitable for testing this patch set, but >>> >> > I need guidance on how to apply it to the Qemu source tree. >>> >> >>> >> You can ask Bernhard to publish a branch with the full work, >>> >> >>> >> >>> >> Hi Chuck, >>> >> >>> >> ... or just visit https://patchew.org/QEMU/20230102213504.14646-1-shentey@gmail.com/ . There you'll find a git tag with a complete history and all instructions! >>> >> >>> >> Thanks for giving my series a test ride! >>> >> >>> >> Best regards, >>> >> Bernhard >>> >> >>> >> or apply each series locally. I use the b4 tool for that: >>> >> https://b4.docs.kernel.org/en/latest/installing.html >>> >> >>> >> i.e.: >>> >> >>> >> $ git checkout -b shentey_work >>> >> $ b4 am 20221120150550.63059-1-shentey@gmail.com >>> >> $ git am >>> >> ./v2_20221120_shentey_decouple_intx_to_lnkx_routing_from_south_bridges.mbx >>> >> $ b4 am 20221221170003.2929-1-shentey@gmail.com >>> >> $ git am >>> >> ./v4_20221221_shentey_this_series_consolidates_the_implementations_of_the_piix3_and_piix4_south.mbx >>> >> $ b4 am 20230102213504.14646-1-shentey@gmail.com >>> >> $ git am ./20230102_shentey_resolve_type_piix3_xen_device.mbx >>> >> >>> >> Now the branch 'shentey_work' contains all the patches and you can test. >>> >> >>> >> Regards, >>> >> >>> >> Phil. >>> >> >>> > >>> >Hi Phil and Bernard, >>> > >>> >I tried applying these 3 patch series on top of the current qemu >>> >master branch. >>> > >>> >Unfortunately, I saw a regression, so I can't give a tested-by tag yet. >>> >>> Hi Chuck, >>> >>> Thanks for your valuable test report! I think the culprit may be commit https://lists.nongnu.org/archive/html/qemu-devel/2023-01/msg00102.html where now 128 PIRQs are considered rather than four. I'll revisit my series and will prepare a v2 in the next days. I think there is no need for further testing v1. >>> >>> Thanks, >>> Bernhard >> >>Hi Bernhard, >> >>Thanks for letting me know I do not need to test v1 further. I agree the >>symptoms are that it is an IRQ problem - it looks like IRQs associated with >>the emulated usb tablet device are not making it to the guest with the >>patched v1 piix device on xen. > > All PCI IRQs were routed to PCI slot 0. This should be fixed in v2 now. > >>I will be looking for your v2 in coming days and try it out also! > > Thank you! Here it is: https://patchew.org/QEMU/20230104144437.27479-1-shentey@gmail.com/ That fixed it! I added my Tested-by tag to the last patch of v2: [PATCH v2 6/6] hw/isa/piix: Resolve redundant TYPE_PIIX3_XEN_DEVICE AFAICT, v2 is is ready to go! Best regards, Chuck
On 1/3/2023 8:38 AM, Bernhard Beschow wrote: > > > On Tue, Jan 3, 2023 at 2:17 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote: > > Hi Chuck, > > On 3/1/23 04:15, Chuck Zmudzinski wrote: > > On 1/2/23 4:34 PM, Bernhard Beschow wrote: > >> This series first renders TYPE_PIIX3_XEN_DEVICE redundant and finally removes > >> it. The motivation is to 1/ decouple PIIX from Xen and 2/ to make Xen in the PC > >> machine agnostic to the precise southbridge being used. 2/ will become > >> particularily interesting once PIIX4 becomes usable in the PC machine, avoiding > >> the "Frankenstein" use of PIIX4_ACPI in PIIX3. > >> > >> Testing done: > >> None, because I don't know how to conduct this properly :( > >> > >> Based-on: <20221221170003.2929-1-shentey@gmail.com> > >> "[PATCH v4 00/30] Consolidate PIIX south bridges" > > This series is based on a previous series: > https://lore.kernel.org/qemu-devel/20221221170003.2929-1-shentey@gmail.com/ > (which itself also is). > > >> Bernhard Beschow (6): > >> include/hw/xen/xen: Make xen_piix3_set_irq() generic and rename it > >> hw/isa/piix: Reuse piix3_realize() in piix3_xen_realize() > >> hw/isa/piix: Wire up Xen PCI IRQ handling outside of PIIX3 > >> hw/isa/piix: Avoid Xen-specific variant of piix_write_config() > >> hw/isa/piix: Resolve redundant k->config_write assignments > >> hw/isa/piix: Resolve redundant TYPE_PIIX3_XEN_DEVICE > >> > >> hw/i386/pc_piix.c | 34 ++++++++++++++++-- > >> hw/i386/xen/xen-hvm.c | 9 +++-- > >> hw/isa/piix.c | 66 +---------------------------------- > > > > This file does not exist on the Qemu master branch. > > But hw/isa/piix3.c and hw/isa/piix4.c do exist. > > > > I tried renaming it from piix.c to piix3.c in the patch, but > > the patch set still does not apply cleanly on my tree. > > > > Is this patch set re-based against something other than > > the current master Qemu branch? > > > > I have a system that is suitable for testing this patch set, but > > I need guidance on how to apply it to the Qemu source tree. > > You can ask Bernhard to publish a branch with the full work, > > > Hi Chuck, > > ... or just visit https://patchew.org/QEMU/20230102213504.14646-1-shentey@gmail.com/ . There you'll find a git tag with a complete history and all instructions! > > Thanks for giving my series a test ride! > > Best regards, > Bernhard > > or apply each series locally. I use the b4 tool for that: > https://b4.docs.kernel.org/en/latest/installing.html > > i.e.: > > $ git checkout -b shentey_work > $ b4 am 20221120150550.63059-1-shentey@gmail.com > $ git am > ./v2_20221120_shentey_decouple_intx_to_lnkx_routing_from_south_bridges.mbx > $ b4 am 20221221170003.2929-1-shentey@gmail.com > $ git am > ./v4_20221221_shentey_this_series_consolidates_the_implementations_of_the_piix3_and_piix4_south.mbx > $ b4 am 20230102213504.14646-1-shentey@gmail.com > $ git am ./20230102_shentey_resolve_type_piix3_xen_device.mbx > > Now the branch 'shentey_work' contains all the patches and you can test. > > Regards, > > Phil. > OK, I didn't see the "Consolidate PIIX south bridges" series is a prerequisite. I will try it - it may take a couple of days because I need to test both patch series in my environment and I can only work on this in my spare time. I will provide Tested-by tags to both series if successful. Otherwise, I will reply with an explanation of any problems. Chuck
Am 3. Januar 2023 17:25:35 UTC schrieb Chuck Zmudzinski <brchuckz@aol.com>: >On 1/3/2023 8:38 AM, Bernhard Beschow wrote: >> >> >> On Tue, Jan 3, 2023 at 2:17 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote: >> >> Hi Chuck, >> >> On 3/1/23 04:15, Chuck Zmudzinski wrote: >> > On 1/2/23 4:34 PM, Bernhard Beschow wrote: >> >> This series first renders TYPE_PIIX3_XEN_DEVICE redundant and finally removes >> >> it. The motivation is to 1/ decouple PIIX from Xen and 2/ to make Xen in the PC >> >> machine agnostic to the precise southbridge being used. 2/ will become >> >> particularily interesting once PIIX4 becomes usable in the PC machine, avoiding >> >> the "Frankenstein" use of PIIX4_ACPI in PIIX3. >> >> >> >> Testing done: >> >> None, because I don't know how to conduct this properly :( >> >> >> >> Based-on: <20221221170003.2929-1-shentey@gmail.com> >> >> "[PATCH v4 00/30] Consolidate PIIX south bridges" >> >> This series is based on a previous series: >> https://lore.kernel.org/qemu-devel/20221221170003.2929-1-shentey@gmail.com/ >> (which itself also is). >> >> >> Bernhard Beschow (6): >> >> include/hw/xen/xen: Make xen_piix3_set_irq() generic and rename it >> >> hw/isa/piix: Reuse piix3_realize() in piix3_xen_realize() >> >> hw/isa/piix: Wire up Xen PCI IRQ handling outside of PIIX3 >> >> hw/isa/piix: Avoid Xen-specific variant of piix_write_config() >> >> hw/isa/piix: Resolve redundant k->config_write assignments >> >> hw/isa/piix: Resolve redundant TYPE_PIIX3_XEN_DEVICE >> >> >> >> hw/i386/pc_piix.c | 34 ++++++++++++++++-- >> >> hw/i386/xen/xen-hvm.c | 9 +++-- >> >> hw/isa/piix.c | 66 +---------------------------------- >> > >> > This file does not exist on the Qemu master branch. >> > But hw/isa/piix3.c and hw/isa/piix4.c do exist. >> > >> > I tried renaming it from piix.c to piix3.c in the patch, but >> > the patch set still does not apply cleanly on my tree. >> > >> > Is this patch set re-based against something other than >> > the current master Qemu branch? >> > >> > I have a system that is suitable for testing this patch set, but >> > I need guidance on how to apply it to the Qemu source tree. >> >> You can ask Bernhard to publish a branch with the full work, >> >> >> Hi Chuck, >> >> ... or just visit https://patchew.org/QEMU/20230102213504.14646-1-shentey@gmail.com/ . There you'll find a git tag with a complete history and all instructions! >> >> Thanks for giving my series a test ride! >> >> Best regards, >> Bernhard >> >> or apply each series locally. I use the b4 tool for that: >> https://b4.docs.kernel.org/en/latest/installing.html >> >> i.e.: >> >> $ git checkout -b shentey_work >> $ b4 am 20221120150550.63059-1-shentey@gmail.com >> $ git am >> ./v2_20221120_shentey_decouple_intx_to_lnkx_routing_from_south_bridges.mbx >> $ b4 am 20221221170003.2929-1-shentey@gmail.com >> $ git am >> ./v4_20221221_shentey_this_series_consolidates_the_implementations_of_the_piix3_and_piix4_south.mbx >> $ b4 am 20230102213504.14646-1-shentey@gmail.com >> $ git am ./20230102_shentey_resolve_type_piix3_xen_device.mbx >> >> Now the branch 'shentey_work' contains all the patches and you can test. >> >> Regards, >> >> Phil. >> > >OK, I didn't see the "Consolidate PIIX south bridges" series is a >prerequisite. > >I will try it - it may take a couple of days because I need to test both >patch series in my environment and I can only work on this in my spare >time. > >I will provide Tested-by tags to both series if successful. Otherwise, >I will reply with an explanation of any problems. Sounds good! You don't need to test the prerequisite though since it is already reviewed. It would be completely sufficient if you could test this series to fill in the gap for my limited Xen knowledge -- thanks! Best regards, Bernhard > >Chuck
© 2016 - 2024 Red Hat, Inc.