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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.01.18 at 11:49, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----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.

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
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel