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
next prev parent 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).