Re: [Xen-devel] gross qemu behavior

[Fabio Fantoni <fabio.fantoni@xxxxxxx>]

Il 05/05/2014 12:35, Jan Beulich ha scritto:
> > > > On 05.05.14 at 12:04, <fabio.fantoni@xxxxxxx> wrote:
> > Il 04/04/2014 18:54, Stefano Stabellini ha scritto:
> > > 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.
> > Any news about this discussion?
> Someone would need to write both hypervisor and qemu side patches
> - are you volunteering?
>
> Jan
Thanks for your reply.
Unfortunately I don't have enough knowledge to do such patches.
I just wanted to know if there was any news.

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