[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/2] x86/hvm: actually release ioreq server pages



> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 24 April 2015 09:01
> To: Paul Durrant
> Cc: Andrew Cooper; xen-devel@xxxxxxxxxxxxxxxxxxxx; Keir (Xen.org)
> Subject: Re: [PATCH 1/2] x86/hvm: actually release ioreq server pages
> 
> >>> On 23.04.15 at 17:46, <paul.durrant@xxxxxxxxxx> wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -496,7 +496,7 @@ static void hvm_free_ioreq_gmfn(struct domain *d,
> unsigned long gmfn)
> >  {
> >      unsigned int i = gmfn - d->arch.hvm_domain.ioreq_gmfn.base;
> >
> > -    clear_bit(i, &d->arch.hvm_domain.ioreq_gmfn.mask);
> > +    set_bit(i, &d->arch.hvm_domain.ioreq_gmfn.mask);
> >  }
> 
> Double checking this I came to wonder whether
> HVM_PARAM_NR_IOREQ_SERVER_PAGES handling isn't broken
> when invoked a second time with a.value smaller than what was
> used the first time, or when any server pages are already in
> use.
> 

Yes, the param is only intended to be a set-once param, the same as 
HVM_PARAM_IOREQ_SERVER_PFN. If the latter were changed after ioreq servers had 
been created then it could also lead to strangeness. I'll put together a patch 
to add checks for both.

  Paul

> Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.