virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Derek Murray <Derek.Murray@cl.cam.ac.uk>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	Jan Beulich <jbeulich@novell.com>,
	Glauber de Oliveira Costa <gcosta@redhat.com>,
	Chris Wright <chrisw@sous-sol.org>,
	"virtualization@lists.osdl.org" <virtualization@lists.osdl.org>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: Re: Next steps with pv_ops for Xen
Date: Wed, 05 Dec 2007 12:15:01 -0800	[thread overview]
Message-ID: <475706C5.1000608@goop.org> (raw)
In-Reply-To: <4756EDF3.30501@cl.cam.ac.uk>

Derek Murray wrote:
> Jeremy Fitzhardinge wrote:
>> Could we use one of the software-defined bits in the PTE to indicate
>> that this is a foreign/granted PTE, and have set_pte_at behave
>> differently if you pass it a pte with this bit set?
>
> Actually, as Gerd pointed out in his answer to his own question, the
> use of VM_DONTCOPY cuts out this entire code path, so we don't need to
> worry about it.
>
> Mind you, it looks like we're going to go ahead and use one of the PTE
> bits to signify foreign PTEs anyway, per Keir's suggestion. Either
> way, it's going to involve making Xen-specific changes to the mm code... 

Sneaking in a user for the otherwise completely unused PTE bits should
be fairly straightforward.

> have you any ideas how we can either (i) get rid of the zap_pte hook
> in the vm_operations_struct, or (ii) make a really compelling case to
> the kernel maintainers that it really should get in? 

Hm, I haven't spent much time looking at how grant tables and their
mappings work yet, so I can't say I really understand all this myself. 
Hence, questions:

Can we take a different approach from the zap_pte hook?  Given that
we're 1) planning on claiming a pte bit for grant mappings, and 2) need
to hook ptep_get_and_clear anyway to solve the mprotect performance
problems, couldn't we just special-case grant mapping pte_clears?

In 2.6.18-xen the only two implementations of zap_pte are
blktap_clear_pte and gntdev_clear_pte.  Given a ptep with the
grant-mapping bit set, could we determine which of these need calling
and do the appropriate thing?  Do we even need separate implementations
of the core pte-clearing functionality?  Could we just say something like:

	if (pte & _PAGE_XEN_FOREIGN)
		HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, ...);
	else
		xen_set_pte_at(...);


blktap_clear_pte and gntdev_clear_pte do other housekeeping, but do they
have to be done at the same instant as the grant mapping clear?  Could
they be done via some other hook?

(I see Gerd just proposed this, pretty much.)

    J

  reply	other threads:[~2007-12-05 20:15 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-21 22:05 Next steps with pv_ops for Xen Stephen C. Tweedie
2007-11-21 23:12 ` Jeremy Fitzhardinge
2007-11-26 14:02   ` Juan Quintela
2007-11-26 18:52     ` Jeremy Fitzhardinge
2007-11-27  8:30       ` Jan Beulich
2007-11-27 17:00         ` Jeremy Fitzhardinge
2007-11-27 17:14           ` Jan Beulich
2007-11-27 17:15           ` Stephen C. Tweedie
2007-12-03 12:54 ` Gerd Hoffmann
2007-12-03 13:19   ` Derek Murray
2007-12-03 14:16     ` Gerd Hoffmann
2007-12-03 14:51       ` Derek Murray
2007-12-03 17:18         ` Mark Williamson
2007-12-03 18:36           ` D.G. Murray
2007-12-03 19:08             ` Mark Williamson
2007-12-04  9:35               ` tgh
2007-12-05  3:42                 ` Mark Williamson
2007-12-06 15:21             ` Gerd Hoffmann
2007-12-06 15:32               ` Derek Murray
2007-12-06 15:55                 ` Gerd Hoffmann
2007-12-21 12:58             ` [Xen-devel] " Gerd Hoffmann
2007-12-03 20:38         ` Gerd Hoffmann
2007-12-04  9:40           ` Derek Murray
2007-12-04 12:01             ` Gerd Hoffmann
2007-12-04 12:39               ` Stephen C. Tweedie
2007-12-04 19:58                 ` Gerd Hoffmann
2007-12-05 11:48                   ` [Xen-devel] " Derek Murray
2007-12-05 13:19                   ` Derek Murray
     [not found]                   ` <47569014.8080008@cl.cam.ac.uk>
2007-12-05 14:12                     ` Gerd Hoffmann
2007-12-05 14:22                       ` Keir Fraser
2007-12-05 14:30                         ` Derek Murray
2007-12-05 16:58                           ` Keir Fraser
2007-12-05 17:17                             ` Derek Murray
2007-12-05 17:22                               ` Keir Fraser
2007-12-05 17:48                                 ` Derek Murray
2007-12-05 17:59                                   ` Keir Fraser
2007-12-05 18:15                                     ` Derek Murray
2007-12-12  8:27                                       ` Isaku Yamahata
2007-12-12  8:39                                         ` Keir Fraser
2007-12-12  8:44                                           ` Isaku Yamahata
2007-12-05 20:06                                     ` Gerd Hoffmann
2007-12-05 18:12                     ` Jeremy Fitzhardinge
2007-12-05 18:29                       ` Derek Murray
2007-12-05 20:15                         ` Jeremy Fitzhardinge [this message]
2007-12-05 20:35                           ` Geoffrey Lefebvre
2007-12-06 10:15                             ` Gerd Hoffmann
2007-12-05 20:44                           ` Keir Fraser
2007-12-06 10:00                             ` Derek Murray
2007-12-06 19:55                               ` [Xen-devel] " Jeremy Fitzhardinge
2007-12-05 10:03                 ` Gerd Hoffmann
2007-12-05 12:51                   ` Gerd Hoffmann
2007-12-05 10:11                 ` Derek Murray

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=475706C5.1000608@goop.org \
    --to=jeremy@goop.org \
    --cc=Derek.Murray@cl.cam.ac.uk \
    --cc=chrisw@sous-sol.org \
    --cc=ehabkost@redhat.com \
    --cc=gcosta@redhat.com \
    --cc=jbeulich@novell.com \
    --cc=kraxel@redhat.com \
    --cc=quintela@redhat.com \
    --cc=virtualization@lists.osdl.org \
    --cc=xen-devel@lists.xensource.com \
    /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).