Re: [PATCH 0/6] Resolve TYPE_PIIX3_XEN_DEVICE

[Bernhard Beschow <shentey@xxxxxxxxx>]

Am 4. Januar 2023 13:11:16 UTC schrieb Chuck Zmudzinski <brchuckz@xxxxxxx>:
>On 1/4/2023 7:13 AM, Bernhard Beschow wrote:
>> Am 4. Januar 2023 08:18:59 UTC schrieb Chuck Zmudzinski <brchuckz@xxxxxxx>:
>> >On 1/3/2023 8:38 AM, Bernhard Beschow wrote:
>> >>
>> >>
>> >> On Tue, Jan 3, 2023 at 2:17 PM Philippe Mathieu-Daudé <philmd@xxxxxxxxxx> 
>> >> 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@xxxxxxxxx>
>> >>     >>            "[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@xxxxxxxxx/
>> >>     (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@xxxxxxxxx/ . 
>> >> 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@xxxxxxxxx
>> >>     $ git am
>> >>     
>> >> ./v2_20221120_shentey_decouple_intx_to_lnkx_routing_from_south_bridges.mbx
>> >>     $ b4 am 20221221170003.2929-1-shentey@xxxxxxxxx
>> >>     $ git am
>> >>     
>> >> ./v4_20221221_shentey_this_series_consolidates_the_implementations_of_the_piix3_and_piix4_south.mbx
>> >>     $ b4 am 20230102213504.14646-1-shentey@xxxxxxxxx
>> >>     $ 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@xxxxxxxxx/

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
>