Re: [PATCH 0/6] Resolve TYPE_PIIX3_XEN_DEVICE

[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.

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