vfio-vga-reset branches build problems

[Mario Ceresa]

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?

Thanks for the attention and best regards,

Mario

[Alex Williamson]

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

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

[Cole Robinson]

On 07/08/2013 11:20 AM, 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) {
>   
Not sure about that, maybe transient qemu breakage.

Since you are having issues, it's probably easier to get closer to the source.
Compiling qemu from git is pretty easy. All you should need is likely

./configure --target-list="x86_64-softmmu" --disable-werror
make
./x86_64-softmmu/qemu-system-x86_64 ...

- Cole