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

From: Paul Durrant <Paul.Durrant@citrix.com>
To: George Dunlap <George.Dunlap@citrix.com>,
	"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>,
	"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 14:57:04 +0000	[thread overview]
Message-ID: <b9216e4ba9694d60b3782ee686223909@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <CAFLBxZaZreeOvT9OwEWuvkA7ihgqh_giodWXQF5LM4BOqm8Y3w@mail.gmail.com>

> -----Original Message-----
> From: George Dunlap
> Sent: 20 April 2016 15:50
> To: Yu, Zhang
> Cc: Paul Durrant; xen-devel@lists.xen.org; Kevin Tian; Jan Beulich; Andrew
> Cooper; Tim (Xen.org); Lv, Zhiyuan; jun.nakajima@intel.com
> Subject: 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 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?
> 

If we ever want to meaningfully migrate a VM with XenGT enabled then I think it has to be possible to migrate the p2m_ioreq_server page types as-is. I'd expect a new instance of the xengt emulator to claim them on the far and any emulator state be transferred in a similar way to which qemu state is transferred such that vgpu emulation can be continued after the migration.
After all, it's not like we magically reset the type of mmio-dm pages on migration. It is just expected that a new instance of QEMU is spawned to take care of them on the far end when the VM is unpaused.

  Paul

> 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