On 6/20/2016 7:20 PM, Jan Beulich wrote:
On 20.06.16 at 13:06, <yu.c.zh...@linux.intel.com> wrote:
On 6/20/2016 6:45 PM, Jan Beulich wrote:
On 20.06.16 at 12:30, <yu.c.zh...@linux.intel.com> wrote:
On 6/20/2016 6:10 PM, George Dunlap wrote:
On 20/06/16 10:03, Yu Zhang wrote:
So one solution is to disallow the log dirty feature in XenGT, i.e. just
return failure when enable_logdirty()
is called in toolstack. But I'm afraid this will restrict XenGT's future
live migration feature.
I don't understand this -- you can return -EBUSY if live migration is
attempted while there are outstanding ioreq_server entries for the time
being, and at some point in the future when this actually works, you can
return success.
Well, the problem is we cannot easily tell if there's any outstanding
p2m_ioreq_server entries.
That's easy to address: Keep a running count.
Oh, sorry, let me try to clarify: here by "outstanding p2m_ioreq_server
entries", I mean the
entries with p2m_ioreq_server type which have not been set back to
p2m_ram_rw by device
model when the ioreq server detaches. But with asynchronous resetting,
we can not differentiate
these entries with the normal write protected ones which also have the
p2m_ioreq_server set.
I guess I'm missing something here, because I can't see why we
can't distinguish them (and also can't arrange for that).
Because both have the same p2m type and access rights.
Sorry, it's my duty to explain this more clearly, but I just realized
it's hard to describe. :)
Let me try to elaborate this with an example:
Suppose resolve_misconfig() is modified to change all p2m_ioreq_server
entries(which also
have e.recalc flag turned on) back to p2m_ram_rw. And suppose we have
ioreq server 1, which
emulates gfn A, and ioreq server 2 which emulates gfn B:
1> At the beginning, ioreq server 1 is attached to p2m_ioreq_server, and
gfn A is write protected
by setting it to p2m_ioreq_server;
2> ioreq server 1 is detached from p2m_ioreq_server, left gfn A's p2m
type unchanged;
3> After the detachment of ioreq server 1,
p2m_change_entry_type_global() is called, all ept
entries are invalidated;
4> Later, ioreq server 2 is attached to p2m_ioreq_server;
5> Gfn B is set to p2m_ioreq_server, although its corresponding ept
entry was invalidated,
ept_set_entry() will trigger resolve_misconfig(), which will set the p2m
type of gfn B back to
p2m_ram_rw;
6> ept_set_entry() will set gfn B's p2m type to p2m_ioreq_server next;
And now, we have two
ept entries with p2m_ioreq_server type - gfn A's and gfn B's.
With no live migration, things could work fine - later accesses to gfn A
will ultimately change
its type back to p2m_ram_rw.
However, if live migration is started(all pte entries invalidated
again), resolve_misconfig() would
change both gfn A's and gfn B's p2m type back to p2m_ram_rw, which means
the emulation of
gfn B would fail.
I tried to further extend the log dirty logic to solve this conflict,
but failed, because we do not
know for sure when the resetting of gfn A will be performed and the code
can not easily tell
the different expectations for gfn A and gfn B because they both have
the same p2m type
and access rights.
Hope you can understand this problem and I would be very appreciated if
you have any suggestion.
Anyway, thanks for your patience! :)
Thanks
yu
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel