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

From: George Dunlap <george.dunlap@citrix.com>
To: "Yu, Zhang" <yu.c.zhang@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	"jun.nakajima@intel.com" <jun.nakajima@intel.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"Tim (Xen.org)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	"Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
Date: Wed, 20 Apr 2016 15:50:08 +0100	[thread overview]
Message-ID: <CAFLBxZaZreeOvT9OwEWuvkA7ihgqh_giodWXQF5LM4BOqm8Y3w@mail.gmail.com> (raw)
In-Reply-To: <57161D9E.6030509@linux.intel.com>

On Tue, Apr 19, 2016 at 12:59 PM, Yu, Zhang <yu.c.zhang@linux.intel.com> 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@lists.xen.org
http://lists.xen.org/xen-devel