Re: [PATCH] x86/ioreq server: Fix DomU couldn't reboot when using p2m_ioreq_server p2m_type

["Jan Beulich" <JBeulich@suse.com>]

>>> On 06.05.17 at 03:51, <xiong.y.zhang@intel.com> wrote:
>> >>> On 05.05.17 at 05:52, <xiong.y.zhang@intel.com> wrote:
>> > 'commit 1679e0df3df6 ("x86/ioreq server: asynchronously reset
>> > outstanding p2m_ioreq_server entries")' will call
>> > p2m_change_entry_type_global() which set entry.recalc=1. Then
>> > the following get_entry(p2m_ioreq_server) will return
>> > p2m_ram_rw type.
>> > But 'commit 6d774a951696 ("x86/ioreq server: synchronously reset
>> > outstanding p2m_ioreq_server entries when an ioreq server unmaps")'
>> > assume get_entry(p2m_ioreq_server) will return p2m_ioreq_server
>> > type, then reset p2m_ioreq_server entries. The fact is the assumption
>> > isn't true, and sysnchronously reset function couldn't work. Then
>> > ioreq.entry_count is larger than zero after an ioreq server unmaps,
>> > finally this results DomU couldn't reboot.
>> 
>> I've had trouble understanding this part already on v1 (btw, why is
>> this one not tagged v2?), and since I still can't figure it I have to ask:
>> Why is it that guest reboot is being impacted here? From what I recall
>> a non-zero count should only prevent migration.
> [Zhang, Xiong Y] Sorry, although they solve the same issue, the solution is
> totally different, so I didn't mark this as V2, I will mark the following
> as v2 with this solution.
> During DomU reboot, it will first unmap ioreq server in shutdown process,
> then it call map ioreq server in boot process. The following sentence in
> p2m_set_ioreq_server() result mapping ioreq server failure, then DomU
> couldn't continue booting.
> If ( read_atomic(&p->ioreq.entry_count))
>    goto out;

It is clear that it would be this statement to be the problem one,
but I continue to not see why this would affect reboot: The rebooted
guest runs in another VM with, hence, a different p2m. I cannot see
why there would be a non-zero ioreq.entry_count the first time an
ioreq server claims the p2m_ioreq_server type for this new domain.

Jan


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