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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Jackson [mailto:ian.jackson@xxxxxxxxxxxxx]
> Sent: 12 December 2016 18:04
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>; Zhang Chen
> <zhangchen.fnst@xxxxxxxxxxxxxx>; Changlong Xie
> <xiecl.fnst@xxxxxxxxxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>; Eddie Dong
> <eddie.dong@xxxxxxxxx>; Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>;
> Ian Jackson <Ian.Jackson@xxxxxxxxxx>; Wen Congyang
> <wencongyang@xxxxxxxxx>; Yang Hongyang <imhy.yang@xxxxxxxxx>; Xen
> devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: RE: [Xen-devel] [PATCH 1/3] Don't create default ioreq server
> 
> Paul Durrant writes ("RE: [Xen-devel] [PATCH 1/3] Don't create default ioreq
> server"):
> > 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.
> 
> (I see further discussion has obviated the need to deal with this,
> but:)
> 
> You mean to patch trad to make a few more hypercalls to explicitly
> create an ioreq server ?  Would it have to register all of its memory
> regions ?  If it wouldn't, then the change to qemu-trad wouldn't be
> too hard.
> 

No, it would have to explicitly register all IO regions too... and understand 
new-fangled PCI config space ioreqs.

  Paul

> qemu-trad is fairly closely tied to the Xen releases so we wouldn't
> have to support the old way for very long.
> 
> Ian.

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