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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

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

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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel