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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On Tue, Apr 19, 2016 at 12:59 PM, Yu, Zhang <yu.c.zhang@xxxxxxxxxxxxxxx> wrote:
>>> So what about the VM suspend case you mentioned above? Will that trigger
>>> the unmapping of ioreq server? Could the device model also take the role
>>> to change the p2m type back in such case?
>>
>>
>> Yes. The device model has to be told by the toolstack that the VM is
>> suspending, otherwise it can't disable the ioreq server which puts the
>> shared ioreq pages back into the guest p2m. If that's not done then the
>> pages will be leaked.
>>
>>>
>>> It would be much simpler if hypervisor side does not need to provide
>>> the p2m resetting logic, and we can support live migration at the same
>>> time then. :)
>>>
>>
>> That really should not be hypervisor's job.
>>
>>    Paul
>>
>
> Oh. So let's just remove the p2m type recalculation code from this
> patch, no need to call p2m_change_entry_type_global, and no need to
> worry about the log dirty part.
>
> George, do you think this acceptable?

Sorry, just to make sure I understand your intentions:

1. The ioreq servers will be responsible for changing all the
p2m_ioreq_server types back to p2m_ram_rw before detaching
2. Xen will refuse to set logdirty mode if there are any attached ioreq servers

The one problem with #1 is what to do if the ioreq server is buggy /
killed, and forgets / is unable to clean up its ioreq_server entries?

There's a certain symmetry with the idea of having the ioreq server
responsible both for mapping and unmapping; and it would be nice to
have this stuff work for shadow mode as well.  But the automatic type
change seems like a more robust option.  (Still open to persuasion on
this.)

On another note: the hard freeze is long past the already-extended
deadline, so I was assuming this was 4.8 material at this point.

 -George

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