Re: [Xen-devel] [PATCH v2 REPOST 12/12] x86/hvm/ioreq: add a new mappable resource type...

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
[snip]
> >> I'm not terribly happy with allocating out-of-band pages either.  One
> >> of the advantages of the way things are done now (with the page
> >> allocated to the guest VM) is that it is more resilient to unexpected
> >> events:  If the domain dies before the emulator is done, you have a
> >> "zombie" domain until the process exits.  But once the process exits
> >> for any reason -- whether crashing or whatever -- the ref is freed and
> >> the domain can finish dying.
> >>
> >> What happens in this case if the dm process in dom0 is killed /
> >> segfaults before it can unmap the page?  Will the page be properly
> >> freed, or will it just leak?
> >
> > The page is referenced by the ioreq server in the target domain, so it will
> be freed when the target domain is destroyed.
> 
> I don't understand how you're using the terms... I would have
> interpreted 'target domain' to me means the guest VM to which emulated
> devices are being provided, and 'ioreq server' means the process
> (perhaps in dom0, perhaps in a stubdomain) which is providing the
> emulated devices.
> 
> Did you mean that it's referenced by the ioreq_server struct in the
> target domain, and so a put_page() will happen when the guest is
> destroyed?

Terminology issues :-) By 'ioreq server' I mean the infrastructure in Xen, 
centred around struct ioreq_server. I refer to the dom0 process/stub 
domain/xengt module/whatever as the 'emulator'.
So, yes, the fact that the page is referenced in the ioreq server of the target 
domain means that a put_page() will happen when that domain is destroyed.

  Paul

> 
>  -George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel