Re: [Xen-devel] [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable resource type...

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 04 January 2018 10:47
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: JulienGrall <julien.grall@xxxxxxx>; Andrew Cooper
> <Andrew.Cooper3@xxxxxxxxxx>; George Dunlap
> <George.Dunlap@xxxxxxxxxx>; Ian Jackson <Ian.Jackson@xxxxxxxxxx>; Wei Liu
> <wei.liu2@xxxxxxxxxx>; StefanoStabellini <sstabellini@xxxxxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx; Konrad Rzeszutek Wilk
> <konrad.wilk@xxxxxxxxxx>; Tim (Xen.org) <tim@xxxxxxx>
> Subject: RE: [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable
> resource type...
> 
> >>> On 03.01.18 at 17:06, <Paul.Durrant@xxxxxxxxxx> wrote:
> >>  -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 03 January 2018 15:48
> >> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> >> Cc: JulienGrall <julien.grall@xxxxxxx>; Andrew Cooper
> >> <Andrew.Cooper3@xxxxxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>; George
> >> Dunlap <George.Dunlap@xxxxxxxxxx>; Ian Jackson
> <Ian.Jackson@xxxxxxxxxx>;
> >> Stefano Stabellini <sstabellini@xxxxxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx;
> >> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>; Tim (Xen.org)
> >> <tim@xxxxxxx>
> >> Subject: Re: [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable
> >> resource type...
> >>
> >> >>> On 03.01.18 at 13:19, <paul.durrant@xxxxxxxxxx> wrote:
> >> > +static void hvm_free_ioreq_mfn(struct hvm_ioreq_server *s, bool
> buf)
> >> > +{
> >> > +    struct domain *d = s->domain;
> >> > +    struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
> >> > +
> >> > +    if ( !iorp->page )
> >> > +        return;
> >> > +
> >> > +    page_list_add_tail(iorp->page, &d-
> >> >arch.hvm_domain.ioreq_server.pages);
> >>
> >> Afaict s->domain is the guest, not the domain containing the
> >> emulator. Hence this new model of freeing the pages is safe only
> >> when the emulator domain is dead by the time the guest is being
> >> cleaned up.
> >
> > From the investigations done w.r.t. the grant table pages I don't think this
> > is the case. The emulating domain will have references on the pages and
> this
> > keeps the target domain in existence, only completing domain destruction
> when
> > the references are finally dropped. I've tested this by leaving an emulator
> > running whilst I 'xl destroy' the domain; the domain remains as a zombie
> > until emulator terminates.
> 
> Actually, after further thinking about this, it looks as if such behavior
> was a problem by itself if the dm domain is unprivileged: It shouldn't
> be allowed to prevent the guest being fully cleaned up, or else it
> would be both a meaningful memory leak as well as a domain ID one,
> eventually leading to the inability to create new domains.
> 

The same applies to PV backend domains grant mapping guest pages.

  Paul

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel