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

[Yu Zhang <yu.c.zhang@linux.intel.com>]

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

Thanks
Yu


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