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

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





On 4/19/2016 5:21 PM, Paul Durrant wrote:
-----Original Message-----
[snip]
Does any other maintainers have any suggestions?

Note that it is a requirement that an ioreq server be disabled before VM
suspend. That means ioreq server pages essentially have to go back to
ram_rw semantics.

    Paul


OK. So it should be hypervisor's responsibility to do the resetting.
Now we probably have 2 choices:
1> we reset the p2m type synchronously when ioreq server unmapping
happens, instead of deferring to the misconfig handling part. This
means performance impact to traverse the p2m table.


Do we need to reset at all. The p2m type does need to be transferred, it will 
just be unclaimed on the far end (i.e. the pages are treated as r/w ram) until 
the emulator starts up there. If that cannot be done without creating yet 
another p2m type to handle logdirty (which seems a suboptimal way of dealing 
with it) then I think migration needs to be disallowed on any domain than 
contains any ioreq_server type pages at this stage.

   Paul


Yes. We need - either the device model or hypervisor should grantee
there's no p2m_ioreq_server pages left after an ioreq server is unmapped
from this type (which is write protected in such senario), otherwise
its emulation might be forwarded to other unexpected device models which
claims the p2m_ioreq_server later.

So I guess approach 2> is your suggestion now.

Besides, previously, Jan also questioned the necessity of resetting the
p2m type when an ioreq server is mapping to the p2m_ioreq_server. His
argument is that we should only allow such p2m transition after an
ioreq server has already mapped to this p2m_ioreq_server. I think his point sounds also reasonable.

Thanks
Yu

Or
2> we just disallow live migration when p2m->ioreq.server is not NULL.
This is not quite accurate, because having p2m->ioreq.server mapped
to p2m_ioreq_server does not necessarily means there would be such
outstanding entries. To be more accurate, we can add some other rough
check, e.g. both check if p2m->ioreq.server against NULL and check if
the hvmop_set_mem_type has ever been triggered once for the
p2m_ioreq_server type.

Both choice seems suboptimal for me. And I wonder if we have any
better solutions?

Thanks
Yu

Thanks in advance! :)
If the answer is, "everything just works", that's perfect.

If the answer is, "Before logdirty mode is set, the ioreq server has the
opportunity to detach, removing the p2m_ioreq_server entries, and
operating without that functionality", that's good too.

If the answer is, "the live migration request fails and the guest
continues to run", that's also acceptable.  If you want this series to
be checked in today (the last day for 4.7), this is probably your best
bet.

    -George





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


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

 


Rackspace

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