[Xen-devel] Re: [PATCH][RFC] Support S3 for MSI interrupt in latest kernel dom0

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 17.12.08 13:27 >>>
>On 17/12/2008 12:11, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>
>> In latest kernel, the pci_save_state will not try to save msi/x_state 
>> anymore,
>> instead, it will try to restore msi state when resume using kernel's msi data
>> structure. This cause trouble for us, since thoese MSI data structure is
>> meaningless in Xen environment.
>> 
>> Several option to resolve this issue:
>> a) Change the latest kernel (as dom0) to still to save/restore the msi 
>> content
>> b) Add a new hypercall, so when dom0 try to restore dom0, it will instruct 
>> Xen
>> HV to restore the content based on Xen's MSI data structure
>
>Could Xen remember the MSI state automatically, as it does for IO-APIC
>presumably already? It knows what vectors are routed where at least, even if
>dom0 has to reprogram the PCI device itself.

That is what the map_guest_pirq() re-invocation is intended for - use the
already known (stored) MSI state to re-setup the device accordingly
(after all, msi_compose_msg() only depends on the vector information
to be able to reconstruct address and data fields).

>I'm not sure about option C. I didn't really understand the patch, but it
>smelt like a hack.

It indeed does to a certain degree, and I had recommended to send it to
the list early in case someone (you?) has a better idea to solve the
problem *without* requiring modern Dom0 to deviate more from native
than necessary (in particular, without requiring any teardown during
suspend), which surely is desirable not only for our forward ported kernel,
but also for pv-ops once it gets MSI enabled, and which is also pretty
logical given the statement above on how easily the message is
re-computed, making storing of the message fields across suspend
superfluous.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel