>>> On 04.01.18 at 11:49, <[email protected]> wrote: >> -----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.
Sure. It is my understanding that this isn't an active problem right now because such helper domains are being destroyed together with their client ones; I hope I'm not wrong with this. Jan _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
