Re: [Xen-devel] [PATCH 1/2] xen, libxc: init msix addr/data with value from qemu via hypercall

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Zhenzhong Duan <zhenzhong.duan@xxxxxxxxxx> 05/09/13 5:02 AM >>>
>On 2013/5/8 20:03, Jan Beulich wrote:
>> But of course I still don't really understand why all of the sudden
>> this needs to be passed in rather than being under the full control
>> of the hypervisor at all times. Perhaps this is related to me not
>> understanding why the kernel would read these values at all:
>> There's no other place in the kernel where the message would
>> be read before first getting written (in fact, apart from the
>> use of __read_msi_msg() by the Xen code, there's only one
>> other user under arch/powerpc/, and there - according to the
>> accompanying comment - this is just to save away the data for
>> later use during resume).
>There is a bug if msi_ad is not passed in.
>
>when driver first load,
>
>kernel.__read_msi_msg()
>(got all zero)

But you don't even comment on the apparently bogus use of the function here.

>kernel.__write_msi_msg(pirq)
>(ioreq passed to qemu as no msixtbl_entry established yet)
>qemu.pt_msi_update_one()
>xc_domain_update_msi_irq()
>(msixtbl_entry dynamicly allocated with msi_ad all zero)
>
>then driver unload,
>...
>driver load again,
>
>kernel.__read_msi_msg()
>(got all zero from xen as accelerated entry just established with all zero)

If all zeroes get returned, why would the flow here be different then above?

>qemu.__write_msi_msg(a new pirq)
>
>pirq would exhaust or fail to map and bind.

I'm afraid your replies are more confusing to me than clarifying...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel