>>> On 03.01.18 at 17:06, <paul.durr...@citrix.com> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 03 January 2018 15:48
>> To: Paul Durrant <paul.durr...@citrix.com>
>> Cc: JulienGrall <julien.gr...@arm.com>; Andrew Cooper
>> <andrew.coop...@citrix.com>; Wei Liu <wei.l...@citrix.com>; George
>> Dunlap <george.dun...@citrix.com>; Ian Jackson <ian.jack...@citrix.com>;
>> Stefano Stabellini <sstabell...@kernel.org>; xen-devel@lists.xenproject.org;
>> Konrad Rzeszutek Wilk <konrad.w...@oracle.com>; Tim (Xen.org)
>> <t...@xen.org>
>> Subject: Re: [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable
>> resource type...
>> 
>> >>> On 03.01.18 at 13:19, <paul.durr...@citrix.com> 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.

Jan


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

Reply via email to