Re: [Xen-devel] [PATCH 1/3] Don't create default ioreq server

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx]
[snip]
> > >
> > >   This bug is caused by the read side effects of
> > > HVM_PARAM_IOREQ_PFN. The migration code needs a way of being
> able to
> > > query whether a default ioreq server exists, without creating one.
> > >
> > >   Can you remember what the justification for the read side effects
> > > were? ISTR that it was only for qemu compatibility until the ioreq server
> work
> > > got in upstream. If that was the case, can we drop the read side effects
> now
> > > and mandate that all qemus explicitly create their ioreq servers (even if
> this
> > > involves creating a default ioreq server for qemu-trad)?
> > >
> >
> > The read side effects are indeed because of the need to support the old
> qemu interface. If trad were patched then we could at least deprecate the
> default ioreq server but I'm not sure how long we'd need to leave it in place
> after that before it was removed. Perhaps it ought to be under a KCONFIG
> option, since it's also a bit of a security hole.
> >
> 
> So.. what can be done about to make COLO work?
> 

Andrew tells me there is a new boolean in Xen which can be used to determine 
whether the domain is under construction or not. QEMU should always be kicked 
off when the domain is under construction so we can limit the read side effect 
using that Boolean. Thus, when domain-comes along later and needs to query the 
magic page pfns, we don't magically get a default ioreq server created when we 
didn't want one. I'll send a patch... should be a one-liner.

  Paul

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