All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>
Cc: "Wei Liu" <wei.liu2@citrix.com>,
	"Ian Campbell" <ian.campbell@citrix.com>,
	"Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
	"Ian Jackson" <ian.jackson@eu.citrix.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH] libxc: introduce a per architecture scratch pfn for temporary grant mapping
Date: Thu, 15 Jan 2015 13:20:05 +0000	[thread overview]
Message-ID: <54B7BE85.5080704@linaro.org> (raw)
In-Reply-To: <54B7BD3F.7090107@citrix.com>

On 15/01/15 13:14, Andrew Cooper wrote:
> For things like grant tables, the toolstack is already capable of using
> add_to_physmap to make the pages mappable, but this is inefficient and
> possibly interferes with the guest physical layout.  I propose a short
> circuit of this which allows the toolstack to map any legitimate physmap
> spaces directly, without having to shuffle them in and out of the
> physmap. i.e. a map foreign hypercall which takes {domid, space, idx} as
> parameters rather than {domid, gfn}.
> 
> For the magic pages, this proposal creates a secondary address space,
> which is intended never for the guest to be able to map.  This can
> remove all the current "magic pages" which live in the low MMIO hole
> (ioreq, bufioreq, mem_event rings, etc), and prevents the need for
> emulation pages ever to be accessible to the guest.

If I'm not mistaken a such solution would require modification in the
kernel. So we would have to keep compatibility with older kernel.

Regards,

-- 
Julien Grall

  reply	other threads:[~2015-01-15 13:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-13 20:10 [PATCH] libxc: introduce a per architecture scratch pfn for temporary grant mapping Julien Grall
2015-01-14 11:03 ` Ian Campbell
2015-01-14 13:32   ` Julien Grall
2015-01-14 12:58 ` Andrew Cooper
2015-01-14 13:20   ` Julien Grall
2015-01-14 13:23     ` Andrew Cooper
2015-01-14 13:26       ` Julien Grall
2015-01-14 13:31       ` Ian Campbell
2015-01-14 13:56         ` Andrew Cooper
2015-01-15 10:45   ` Tim Deegan
2015-01-15 13:14     ` Andrew Cooper
2015-01-15 13:20       ` Julien Grall [this message]
2015-01-21 12:03 ` Julien Grall
2015-01-21 12:07   ` Andrew Cooper

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=54B7BE85.5080704@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.