Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.06.16 at 12:10, <george.dunlap@xxxxxxxxxx> wrote:
> On 20/06/16 10:03, Yu Zhang wrote:
>> However, there are conflicts if we take live migration  into account,
>> i.e. if the live migration is
>> triggered by the user(unintentionally maybe) during the gpu emulation
>> process, resolve_misconfig()
>> will set all the outstanding p2m_ioreq_server entries to p2m_log_dirty,
>> which is not what we expected,
>> because our intention is to only reset the outdated p2m_ioreq_server
>> entries back to p2m_ram_rw.
> 
> Well the real problem in the situation you describe is that a second
> "lazy" p2m_change_entry_type_global() operation is starting before the
> first one is finished.  All that's needed to resolve the situation is
> that if you get a second p2m_change_entry_type_global() operation while
> there are outstanding entries from the first type change, you have to
> finish the first operation (i.e., go "eagerly" find all the
> misconfigured entries and change them to the new type) before starting
> the second one.

Eager resolution of outstanding entries can't be the solution here, I
think, as that would - afaict - be as time consuming as doing the type
change synchronously right away. p2m_change_entry_type_global(),
at least right now, can be invoked freely without prior type changes
having fully propagated. The logic resolving mis-configured entries
simply needs to be able to know the correct new type. I can't see
why this logic shouldn't therefore be extensible to this new type
which can be in flight - after we ought to have a way to know what
type a particular GFN is supposed to be?

Jan


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