> -----Original Message----- > From: Jan Beulich [mailto:[email protected]] > Sent: 04 January 2018 10:47 > To: Paul Durrant <[email protected]> > Cc: JulienGrall <[email protected]>; Andrew Cooper > <[email protected]>; George Dunlap > <[email protected]>; Ian Jackson <[email protected]>; Wei Liu > <[email protected]>; StefanoStabellini <[email protected]>; xen- > [email protected]; Konrad Rzeszutek Wilk > <[email protected]>; Tim (Xen.org) <[email protected]> > Subject: RE: [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable > resource type... > > >>> On 03.01.18 at 17:06, <[email protected]> wrote: > >> -----Original Message----- > >> From: Jan Beulich [mailto:[email protected]] > >> Sent: 03 January 2018 15:48 > >> To: Paul Durrant <[email protected]> > >> Cc: JulienGrall <[email protected]>; Andrew Cooper > >> <[email protected]>; Wei Liu <[email protected]>; George > >> Dunlap <[email protected]>; Ian Jackson > <[email protected]>; > >> Stefano Stabellini <[email protected]>; xen- > [email protected]; > >> Konrad Rzeszutek Wilk <[email protected]>; Tim (Xen.org) > >> <[email protected]> > >> Subject: Re: [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable > >> resource type... > >> > >> >>> On 03.01.18 at 13:19, <[email protected]> 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 [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
