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
|
Home