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

Re: [PATCH v4] tools/foreignmem: Support querying the size of a resource


  • To: Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 29 Jan 2021 15:59:48 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/sAOJx6bSqG3W+eYF/HmUOyJbIhZ1d6sNKdhQs57yGQ=; b=Ec5AquIbiuHxJYWCQnp49kI7J/Kya6MDIimv5VOsPK/Ydf55MffVixxs6kGFJGKHLTIFAj1PFPh0Q6fL26Umtb4DzEZyb8/sLVAMSNeo5bqNXu/3lfLDVWgodtyTl1N5+nORK2sPGrinBSj0Iaor6pG8RWcqd8RFGp7Gs+dmpKsdg2nzX6ZW4rSHqfOItvSsgzwSle0BloGUegs7mYATFhssM0Lya/0azy6mZEYBwS8ymwh1WRkkQAShpmRb6ANRX1NqrpNLPb/fAW234r7i7+KlcehPe0Cb+DQN/Rgcoo2KchaWlRg6ut/tOspI0daHtb00HcM7b9e8FQpzydThCQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IDjOmnLK9xst7DVDW/wGXXZILB9txnuZOH1H0q60ALTyKhDpZ7slOOemu5A8a8RoiRqGnb2M46l6mLSgl6G9ISjiwqZ7Ib8T0QuXy97PCe0QnpcXX4Y6R8uzSufzdUpQT6XIWEizDA5dGv7r6QoFEKMc8W7k3y2T0TvZWbQT9C4zkpaxNs6Uz57JhMhDb9PclvZ3khXoB5B43hXsfGWaf75yM0eR8FZ6v5ffflPP7h4jA7g8xu3NInwejJSQE+LRJeIi9AZKQuCOoo/64BOURm+5UMA1KMmQta0gA/d4DbZsclhlCJkQkWvGQdWxK2gxxs4MR+uKpO4xORqJokFumw==
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Paul Durrant <paul@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Micha? Leszczy?ski <michal.leszczynski@xxxxxxx>, Hubert Jasudowicz <hubert.jasudowicz@xxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • Delivery-date: Fri, 29 Jan 2021 15:00:06 +0000
  • Ironport-sdr: d9dd/Jx8lIoEvjJ6m3nFy5I7utbrERfaRFKFjqYEeqsUmtSzhEDLo2mAm4hDBWrtnWxiYYP8yM w4VrH71Yd73I2dOHq3BrlkBfTg4pIr3SaCD5DpT8BoAg/BiysmG8NR4jzKgay2iIyRHEm9v0rl rpjuVitytSqqj/4lrUIZ/5bO9Lu7kSMWxXQXuBmWB7eELf+TePyUGRnpaL3ghHoss897/Dhckg R00G8NkONdXQiSIuDBeJvyPHyYFZCMsuI8O/1jAczB3+Tmyz3HEPrrzRByxmlI/CEz78UhLQZX 4Ls=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, Jan 29, 2021 at 11:38:43AM +0100, Manuel Bouyer wrote:
> On Thu, Jan 28, 2021 at 12:01:52PM +0000, Andrew Cooper wrote:
> > With the Xen side of this interface (soon to be) fixed to return real sizes,
> > userspace needs to be able to make the query.
> > 
> > Introduce xenforeignmemory_resource_size() for the purpose, bumping the
> > library minor version.
> > 
> > Update both all osdep_xenforeignmemory_map_resource() implementations to
> > understand size requests, skip the mmap() operation, and copy back the
> > nr_frames field.
> > 
> > For NetBSD, also fix up the ioctl() error path to issue an unmap(), which 
> > was
> > overlooked by c/s 4a64e2bb39 "libs/foreignmemory: Implement on NetBSD".
> > [....]
> > diff --git a/tools/libs/foreignmemory/netbsd.c 
> > b/tools/libs/foreignmemory/netbsd.c
> > index d26566f601..4ae60aafdd 100644
> > --- a/tools/libs/foreignmemory/netbsd.c
> > +++ b/tools/libs/foreignmemory/netbsd.c
> > @@ -132,6 +132,10 @@ int osdep_xenforeignmemory_map_resource(
> >      };
> >      int rc;
> >  
> > +    if ( !fres->addr && !fres->nr_frames )
> > +        /* Request for resource size.  Skip mmap(). */
> > +        goto skip_mmap;
> > +
> >      fres->addr = mmap(fres->addr, fres->nr_frames << PAGE_SHIFT,
> >                        fres->prot, fres->flags | MAP_ANON | MAP_SHARED, -1, 
> > 0);
> 
> What happens if fres->addr is not NULL and nr_frames is 0 ?

mmap would return MAP_FAILED and errno == EINVAL in that case AFAICT
on Linux and FreeBSD. NetBSD mmap man page doesn't seem to mention
what happens in that case, so the comments below apply to Linux and
FreeBSD. Maybe we need to handle this differently for NetBSD?

> Is it supposed to happen ?

I think that's fine. Calling osdep_xenforeignmemory_map_resource with
nr_frames == 0 is pointing to a bug in the caller, so returning error
should be fine.

> Should we assert that fres->addr is NULL when
> nr_frames is 0 ? Or force fres->addr to NULL when nr_frames is 0 ?

Doesn't really matter, mmap will return EINVAL if nr_frames == 0
regardless of the value of addr.

Roger.



 


Rackspace

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