Re: [Xen-devel] dom0 kernel - irq nobody cared ... the continuing saga ..

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Sander Eikelenboom <linux@xxxxxxxxxxxxxx> 02/10/15 5:01 PM >>>
>Tuesday, February 10, 2015, 2:26:43 PM, you wrote:
>>>> On 10.02.15 at 14:07, <linux@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel