[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 6/20/2016 7:20 PM, Jan Beulich wrote:
On 20.06.16 at 13:06, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote:
On 6/20/2016 6:45 PM, Jan Beulich wrote:
On 20.06.16 at 12:30, <yu.c.zhang@xxxxxxxxxxxxxxx> 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

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! :)


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.