Re: [Xen-devel] gross qemu behavior

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 4 Apr 2014, Jan Beulich wrote:
> >>> On 04.04.14 at 17:32, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > On Fri, 4 Apr 2014, Jan Beulich wrote:
> >> >>> On 04.04.14 at 15:53, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> >> > On Fri, 4 Apr 2014, Jan Beulich wrote:
> >> >> No, it should just never appear at the wrong address. As I said above,
> >> >> I'd consider it halfway acceptable if it remained mapped despite an
> >> >> unmap, but I do think that a proper solution (properly unmapping
> >> >> without de-allocating) can and should be found.
> >> > 
> >> > There is no way to do it today AFAICT.
> >> > Would you care of proposing an hypercall that would support this
> >> > scenario?
> >> 
> >> Hypercall? Everything you need is there afaict.
> > 
> > Maybe I am missing something.
> > 
> > Moving the PCI ROM to the right place in the guest physmap is easy.
> > However how do you think we could unmap the memory (remove it from the
> > guest physmap) without deallocating it?
> > The only hypercall we have is xc_domain_add_to_physmap at the moment.
> 
> XENMEM_remove_from_physmap should be quite suitable here, but
> that is not your problem. The problem is that XENMEM_add_to_physmap
> requires a GFN to be passed in, i.e. assumes that a page to be mapped
> is already mapped somewhere in the guest. (The term "add" in this
> context is rather confusing, as in the GMFN map space case the page
> isn't being added, but moved.) So indeed there is functionality missing
> in the hypervisor.

Right.

After we call XENMEM_remove_from_physmap, there is no way of adding back
the pages to the physmap without knowing the corresponding mfns.  Even
if we knew the mfns of the original allocation, relying on them is
probably not a good idea because the pages could theoretically be
offlined or shared.

This is the reason why I was asking for the hypercall you had in mind to
solve this problem.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel