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-----
[snip]
> >> Does any other maintainers have any suggestions?
> >
> > Note that it is a requirement that an ioreq server be disabled before VM
> suspend. That means ioreq server pages essentially have to go back to
> ram_rw semantics.
> >
> >    Paul
> >
> 
> OK. So it should be hypervisor's responsibility to do the resetting.
> Now we probably have 2 choices:
> 1> we reset the p2m type synchronously when ioreq server unmapping
> happens, instead of deferring to the misconfig handling part. This
> means performance impact to traverse the p2m table.
> 

Do we need to reset at all. The p2m type does need to be transferred, it will 
just be unclaimed on the far end (i.e. the pages are treated as r/w ram) until 
the emulator starts up there. If that cannot be done without creating yet 
another p2m type to handle logdirty (which seems a suboptimal way of dealing 
with it) then I think migration needs to be disallowed on any domain than 
contains any ioreq_server type pages at this stage.

  Paul

> Or
> 2> we just disallow live migration when p2m->ioreq.server is not NULL.
> This is not quite accurate, because having p2m->ioreq.server mapped
> to p2m_ioreq_server does not necessarily means there would be such
> outstanding entries. To be more accurate, we can add some other rough
> check, e.g. both check if p2m->ioreq.server against NULL and check if
> the hvmop_set_mem_type has ever been triggered once for the
> p2m_ioreq_server type.
> 
> Both choice seems suboptimal for me. And I wonder if we have any
> better solutions?
> 
> Thanks
> Yu
> 
> >> Thanks in advance! :)
> >>>> If the answer is, "everything just works", that's perfect.
> >>>>
> >>>> If the answer is, "Before logdirty mode is set, the ioreq server has the
> >>>> opportunity to detach, removing the p2m_ioreq_server entries, and
> >>>> operating without that functionality", that's good too.
> >>>>
> >>>> If the answer is, "the live migration request fails and the guest
> >>>> continues to run", that's also acceptable.  If you want this series to
> >>>> be checked in today (the last day for 4.7), this is probably your best
> >>>> bet.
> >>>>
> >>>>    -George
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >> Regards
> >> Yu
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel
> >
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel