From: Paulina Szubarczyk <firstname.lastname@example.org>
To: David Vrabel <email@example.com>
Cc: firstname.lastname@example.org, email@example.com,
Subject: Re: [PATCH v2 2/2] qdisk - hw/block/xen_disk: grant copy implementation
Date: Wed, 15 Jun 2016 18:55:56 +0200 [thread overview]
Message-ID: <1466009756.15586.4.camel@localhost> (raw)
On Mon, 2016-06-13 at 11:58 +0100, David Vrabel wrote:
> On 13/06/16 11:44, Paulina Szubarczyk wrote:
> > On Mon, 2016-06-13 at 11:15 +0100, David Vrabel wrote:
> >> On 13/06/16 10:43, Paulina Szubarczyk wrote:
> >>> Copy data operated on during request from/to local buffers to/from
> >>> the grant references.
> >>> Before grant copy operation local buffers must be allocated what is
> >>> done by calling ioreq_init_copy_buffers. For the 'read' operation,
> >>> first, the qemu device invokes the read operation on local buffers
> >>> and on the completion grant copy is called and buffers are freed.
> >>> For the 'write' operation grant copy is performed before invoking
> >>> write by qemu device.
> >>> A new value 'feature_grant_copy' is added to recognize when the
> >>> grant copy operation is supported by a guest.
> >>> The body of the function 'ioreq_runio_qemu_aio' is moved to
> >>> 'ioreq_runio_qemu_aio_blk' and in the 'ioreq_runio_qemu_aio' depending
> >>> on the support for grant copy according checks, initialization, grant
> >>> operation are made, then the 'ioreq_runio_qemu_aio_blk' function is
> >>> called.
> >> I think you should add an option to force the use of grant mapping even
> >> if copy support is detected. If future changes to the grant map
> >> infrastructure makes it faster or if grant map scales better in some
> >> systems, then it would be useful to be able to use it.
> > The 'feature_grant_copy' is a boolean and could be set to false in such case.
> > There could be added a node in XenStore, for example
> > 'feature-force-grant-map', which when set by frontend will be read
> > during a connection and changed the value to false forcing the grant map
> > operation.
> This option should not be exposed/controlled by the frontend. I was
> thinking of a command line option to qemu or similar.
I think then there should be possibility for setting this in
xl block-attach <disk-spec-component(s)> and in the config file that
defines the domain in the corresponding fields. But if there is
a need for such feature I would rather do it in a different patch.
Xen-devel mailing list
prev parent reply other threads:[~2016-06-15 16:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-13 9:43 [PATCH v2 0/2] qemu-qdisk: Implementation of grant copy operation Paulina Szubarczyk
2016-06-13 9:43 ` [PATCH v2 1/2] libs, libxc: Interface for " Paulina Szubarczyk
2016-06-13 10:04 ` David Vrabel
2016-06-16 12:16 ` Wei Liu
2016-06-16 12:36 ` David Vrabel
2016-06-16 12:50 ` Wei Liu
2016-06-17 16:43 ` Wei Liu
2016-06-17 17:27 ` Paulina Szubarczyk
2016-06-13 9:43 ` [PATCH v2 2/2] qdisk - hw/block/xen_disk: grant copy implementation Paulina Szubarczyk
2016-06-13 10:15 ` David Vrabel
2016-06-13 10:44 ` Paulina Szubarczyk
2016-06-13 10:58 ` David Vrabel
2016-06-15 16:55 ` Paulina Szubarczyk [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).