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

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

In fact, I think this patch is something like hack the PHYSDEVOP_map_pirq 
hypercall for the restore usage.
Currently the PHYSDEVOP_map_pirq will allocate the irq/vector , setup the 
irq_desc, programe the physical device etc. With this patch added, when used 
for resume, it will used mainly for programe the physical device, since the 
irq/vector/irq_desc is ready, and not like what the name implied (map_pirq) 
anymore.

As for guest side, I assume it will be not complex (Jan may have more 
estimate), but we are not sure if the new hypercall is acceptable for Suse.

Thanks
Yunhong Jiang

Keir Fraser <mailto:keir.fraser@xxxxxxxxxxxxx> wrote:
> On 17/12/2008 15:31, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
> 
>>>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 17.12.08 16:22 >>>
>>> Well, maybe it's okay then. I don't think Yunhong's patch was a good
>>> argument for it -- looking again it appears to have plenty of not really
>>> related chunks contained in it.
>> 
>> I don't think it's really okay as-is: As he indicated, there may be side
>> effects of the changes during other than resume from S3 (in particular
>> the IRQ_GUEST check around the newly added call to ->startup()), and
>> I was hoping you might have a suggestion on how to better distinguish
>> that particular case. In the worst case, Xen has to set another flag in
>> each MSI irq_desc when it resumes from S3, and do the startup as well
>> as the clearing of the flag when map_domain_pirq runs first for that
>> particular vector.
> 
> Then do it as a new hypercall? How much complexity does that add on the
> guest side? 
> 
> -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel