xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Paulina Szubarczyk <paulinaszubarczyk@gmail.com>
To: David Vrabel <dvrabel@cantab.net>
Cc: sstabellini@kernel.org, wei.liu2@citrix.com,
	George.Dunlap@eu.citrix.com, ian.jackson@eu.citrix.com,
	P.Gawkowski@ii.pw.edu.pl, anthony.perard@citrix.com,
	xen-devel@lists.xenproject.org, roger.pau@citrix.com
Subject: Re: [PATCH RESEND 1/4] libs, gnttab, libxc: Interface for grant copy operation
Date: Wed, 01 Jun 2016 09:45:21 +0200	[thread overview]
Message-ID: <1464767121.8602.13.camel@localhost> (raw)
In-Reply-To: <b1103791-af15-24cf-667e-4cb43c30b0f8@cantab.net>

On Tue, 2016-05-31 at 10:25 +0100, David Vrabel wrote:
> 
> On 31/05/2016 05:44, Paulina Szubarczyk wrote:
> > Implentation of interface to grant copy operation called through
> > libxc. An ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..) system call is
> > invoked for linux. In the mini-os the operation is yet not
> > implemented.
> > 
> > * In the file "tools/include/xen-sys/Linux/gntdev.h" added
> >   - 'struct ioctl_gntdev_grant_copy_segment'
> >     The structure is analogous to 'struct gntdev_grant_copy_segment'
> >     defined in linux code include/uapi/xen/gntdev.h. Typdefs are
> >     replaced by they original types:
> >       typedef uint16_t domid_t;
> >       typedef uint32_t grant_ref_t;
> >     That leads to defining domids array with type uint16_t in libs,
> >     differently then in other functions concerning grant table
> >     operations in that library.
> > 
> > ` - macro #define IOCTL_GNTDEV_GRANT_COPY
> > 
> >   - 'struct ioctl_gntdev_grant_copy'
> >     taken from linux code as higher. Structure aggregating
> >     'struct gntdev_grant_copy_segment'
> > 
> > * In the file libs/gnttab/linux.c
> >   - function int osdep_gnttab_grant_copy(xengnttab_handle *xgt,
> >                               uint32_t count,
> >                               uint16_t *domids, uint32_t *refs, void
> >                               **bufs, uint32_t *offset, uint32_t *len,
> >                               int type, uint32_t notify_offset,
> >                               evtchn_port_t notify_port)
> > 
> >     It is a function used to perform grant copy opertion. It allocats
> >     'ioctl_gntdev_grant_copy' and 'ioctl_gntdev_grant_copy_segment'.
> >     Segments are filled from the passed values.
> > 
> >     When @type is different then zero the source to copy from are guest
> >     domain grant pages addressed by @refs and the destination is local
> >     memory accessed from @bufs, the operation flag is then set to
> >     'GNTCOPY_source_gref', contrarily for @type equal zero.
> > 
> >     @offset is the offset on the page
> >     @len is the amount of data to copy,
> >     @offset[i] + @len[i] should not exceed XEN_PAGE_SIZE
> >         - the condition is checked in gntdev device.
> > 
> >     Notification is yet not implemented.
> 
> I'm not sure what you mean by "notifcation" here.
There is notify interface for grant map operations to communicate a
failure to the peer in case of teardown if the notify_port is given
to allow it to take care of resources. I have not checked yet how is it
used.
> 
> > index caf6fb4..0ca07c9 100644
> > --- a/tools/include/xen-sys/Linux/gntdev.h
> > +++ b/tools/include/xen-sys/Linux/gntdev.h
> > @@ -147,4 +147,25 @@ struct ioctl_gntdev_unmap_notify {
> >  /* Send an interrupt on the indicated event channel */
> >  #define UNMAP_NOTIFY_SEND_EVENT 0x2
> >  
> > +struct ioctl_gntdev_grant_copy_segment {
> > +    union {
> > +        void *virt;
> > +        struct {
> > +            uint32_t ref;
> > +            uint16_t offset;
> > +            uint16_t domid;
> > +        } foreign;
> > +    } source, dest;
> > +    uint16_t len;
> > +    uint16_t flags;
> > +    int16_t status;
> > +};
> > +
> > +#define IOCTL_GNTDEV_GRANT_COPY \
> > +_IOC(_IOC_NONE, 'G', 8, sizeof(struct ioctl_gntdev_grant_copy))
> > +struct ioctl_gntdev_grant_copy {
> > +    unsigned int count;
> > +    struct ioctl_gntdev_grant_copy_segment *segments;
> > +};
> > +
> >  #endif /* __LINUX_PUBLIC_GNTDEV_H__ */
> > diff --git a/tools/libs/gnttab/gnttab_core.c b/tools/libs/gnttab/gnttab_core.c
> > index 5d0474d..1e014f8 100644
> > --- a/tools/libs/gnttab/gnttab_core.c
> > +++ b/tools/libs/gnttab/gnttab_core.c
> > @@ -113,6 +113,18 @@ int xengnttab_unmap(xengnttab_handle *xgt, void *start_address, uint32_t count)
> >      return osdep_gnttab_unmap(xgt, start_address, count);
> >  }
> >  
> > +int xengnttab_copy_grant(xengnttab_handle *xgt,
> > +                         uint32_t count,
> > +                         uint16_t *domids,
> > +                         uint32_t *refs,
> > +                         void **bufs,
> > +                         uint32_t *offset, 
> > +                         uint32_t *len,
> > +                         int type)
> 
> This interface should match the ioctl which matches the hypercall.  In
> particular the ioctl (and hypercall) allows copies to and from grant
> references in the same call and returns a per-op status.
> 
I followed the pattern of declaration for the grant map in this file
which as I believe is generic due to the use of it by both linux and
mini-os. 

The header with 'struct ioctl_gntdev_copy_segment' is linked only to the
linux part which issues the hypercall by gntdev, whereas mini-os does
not use gntdev it is not accessible at the higher level.

> Using the same structure in libxc would also allow you to a) remove the
> memory allocations; and b) avoid having to fill in a different structure.
> 
> I would suggest:
> 
> int xengnttab_copy_grant(xengnttab_handle *xgt,
> 	unsigned int count,
> 	xengnttab_copy_segment_t *segs);
> 
> With:
> 
> typedef struct ioctl_gntdev_copy_segment xengnttab_copy_segment_t;
> 
> You should put the required struct ioctl_gntdev_grant_copy on the stack
> since it is small.
> 
> David

Paulina



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

  reply	other threads:[~2016-06-01  7:46 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-31  4:44 [PATCH RESEND 0/4] qemu-qdisk: Replace grant map by grant copy Paulina Szubarczyk
2016-05-31  4:44 ` [PATCH RESEND 1/4] libs, gnttab, libxc: Interface for grant copy operation Paulina Szubarczyk
2016-05-31  9:25   ` David Vrabel
2016-06-01  7:45     ` Paulina Szubarczyk [this message]
2016-06-01 11:22       ` David Vrabel
2016-06-01 11:42         ` Paulina Szubarczyk
2016-06-02  9:37   ` Roger Pau Monné
2016-06-06 14:47   ` Wei Liu
2016-05-31  4:44 ` [PATCH RESEND 2/4] qdisk, hw/block/xen_disk: Removal of grant mapping Paulina Szubarczyk
2016-05-31  9:26   ` David Vrabel
2016-06-02  9:41   ` Roger Pau Monné
2016-06-02  9:57     ` Paulina Szubarczyk
2016-06-02 10:22       ` David Vrabel
2016-05-31  4:44 ` [PATCH RESEND 3/4] qdisk, hw/block/xen_disk: Perform grant copy instead of grant map Paulina Szubarczyk
2016-05-31  9:37   ` David Vrabel
2016-06-01  7:52     ` Paulina Szubarczyk
2016-06-01 11:15       ` David Vrabel
2016-06-02 13:47   ` Roger Pau Monné
2016-05-31  4:44 ` [PATCH RESEND 4/4] qemu-xen-dir/hw/block: Cache local buffers used in grant copy Paulina Szubarczyk
2016-06-02 14:19   ` Roger Pau Monné
2016-06-07 13:13     ` Paulina Szubarczyk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1464767121.8602.13.camel@localhost \
    --to=paulinaszubarczyk@gmail.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=P.Gawkowski@ii.pw.edu.pl \
    --cc=anthony.perard@citrix.com \
    --cc=dvrabel@cantab.net \
    --cc=ian.jackson@eu.citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).