Re: [fedora-virt] vfio-vga-reset branches build problems

[Mario Ceresa]

Thanks Alex for your prompt response!

Of course, I imagined that it was something like that. The nice thing is
that the kernel part can be built up to at least 3.9.8-300, which is fine
for me. As per qemu, I'll try with qemu 1.5.1 which is on rawhide.

Do you have a spec file or list of config options to build your qemu
branch? Are you maybe willing to share them? I'm not sure how to get all
the configure options right otherwise.

Thanks for all your work on that,

Best regards,

Mario


On 8 July 2013 17:46, Alex Williamson <alex.williamson(a)redhat.com&gt; wrote:

>  On Mon, 2013-07-08 at 17:20 +0200, Mario Ceresa wrote:
>  > Dear all,
>  > I'm trying to compile Alex's vfio-vga-reset branches.
>  >
>  > However, I have the following problems:
>  >
>  > * I cannot apply the changes on top of fedora kernel 3.9.9-301.fc19.
>  Doing
>  > on 3.9.8-300.fc19 is fine though.
>  >
>  > * I cannot compile qemu-vfio using fedora's spec (qemu-1.4.2-4.fc19 and
>  > newer). I get:
>  >
>  > qmp.c: In function 'qmp_cpu_add':
>  > qmp.c:114:24: error: 'QEMUMachine' has no member named
> 'hot_add_cpu'
>  >      if (current_machine->hot_add_cpu) {
>  >
>  > Anybody has any suggestions?
>
>  This is really not surprising at all, these branches are just a
>  development snapshot.  The qemu changes are based on something much
>  closer to qemu 1.5 and the kernel changes touch core PCI code, so are
>  bound to get broken as the kernel progresses.
>
>  FWIW, I'm still stuck on how to reliably do the PCI secondary bus reset.
>  In most cases it works fine so long as the guest is properly shut down
>  or rebooted.  However if I issue a system_reset to the guest while it's
>  running, the PCI bus never comes back from reset.  The link status of
>  the root port reports that it's stuck in training mode.  A host reboot
>  is required to recover the bus.  I assume it has to be related to
>  ongoing DMA across the bridge during reset, but disabling the devices
>  and the bridge via the command register and even stopping the guest for
>  reset isn't able to prevent the bus dying.  Suggestions or reports
>  welcome.  I can reliably reproduce by simply calling system_reset on an
>  idle Win7/x64 guest with HD5450 assigned and Catalyst drivers loaded
>  (AMD/990FX host).  Thanks,
>
>  Alex
>
>