>>> Sander Eikelenboom <li...@eikelenboom.it> 02/10/15 5:01 PM >>> >Tuesday, February 10, 2015, 2:26:43 PM, you wrote: >>>> On 10.02.15 at 14:07, <li...@eikelenboom.it> wrote: >> I don't really know how this code is supposed to work (we don't use >> it in our kernels), but it seems the more interesting question is what >> happens when xen_pcibk_do_op() calls this function. I also note there >> is a sysfs interface to control some aspects of this, but I can't see how >> that would work when it only sets ->isr_on but doesn't install the IRQ >> handler if it isn't already installed.
>Suse is still forward porting and not considering upstream/pvops ? We're preparing to switch, but we aren't there yet. >So this one is up to Konrad i guess ... Indeed. >I haven't checked the call chain of xen_pcibk_do_op .. but that could be a >side effect of libxl not imitating pci-front good enough (since HVM guests >don't use the pci-front driver, but instead rely on libxl and Qemu to play >those parts. I thought the frontend functionality was entirely in qemu. Does this behave identical between qemu-trad and qemu-upstream? >One of the issues i already mentioned that devices never get to the state >connected, for HVM guests. The backend state stays 3 (XenbusStateInitialised) >and the frontend state stays 1 (XenbusStateInitialising). That sounds wrong too - not sure from where this state are driven for pcifront (see above). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
