xen-devel
Re: [Xen-devel] Re: Next steps with pv_ops for Xen
To: |
Derek Murray <Derek.Murray@xxxxxxxxxxxx> |
Subject: |
Re: [Xen-devel] Re: Next steps with pv_ops for Xen |
From: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
Date: |
Wed, 05 Dec 2007 12:15:01 -0800 |
Cc: |
"xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Eduardo Habkost <ehabkost@xxxxxxxxxx>, Juan Quintela <quintela@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Glauber de Oliveira Costa <gcosta@xxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxxxxxx>, "virtualization@xxxxxxxxxxxxxx" <virtualization@xxxxxxxxxxxxxx>, Gerd Hoffmann <kraxel@xxxxxxxxxx> |
Delivery-date: |
Wed, 05 Dec 2007 12:15:40 -0800 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
In-reply-to: |
<4756EDF3.30501@xxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<1195682725.6726.48.camel@xxxxxxxxxxxxxxxxxxxxx> <4753FC6A.4020601@xxxxxxxxxx> <4754024C.7020905@xxxxxxxxxxxx> <47540FB8.8000106@xxxxxxxxxx> <475417E7.9070006@xxxxxxxxxxxx> <47546931.2090602@xxxxxxxxxx> <475520A1.6080909@xxxxxxxxxxxx> <475541A8.7030100@xxxxxxxxxx> <1196771999.10809.18.camel@xxxxxxxxxxxxxxxxxxxxx> <4755B158.3030008@xxxxxxxxxx> <47569014.8080008@xxxxxxxxxxxx> <4756E9F2.4050502@xxxxxxxx> <4756EDF3.30501@xxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Thunderbird 2.0.0.9 (X11/20071115) |
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Xen-devel] Re: Next steps with pv_ops for Xen, (continued)
- Re: [Xen-devel] Re: Next steps with pv_ops for Xen, Gerd Hoffmann
- Re: [Xen-devel] Re: Next steps with pv_ops for Xen, Jeremy Fitzhardinge
- Re: [Xen-devel] Re: Next steps with pv_ops for Xen, Derek Murray
- Re: [Xen-devel] Re: Next steps with pv_ops for Xen,
Jeremy Fitzhardinge <=
- Re: [Xen-devel] Re: Next steps with pv_ops for Xen, Geoffrey Lefebvre
- Re: [Xen-devel] Re: Next steps with pv_ops for Xen, Gerd Hoffmann
- Re: [Xen-devel] Re: Next steps with pv_ops for Xen, Keir Fraser
- Re: [Xen-devel] Re: Next steps with pv_ops for Xen, Derek Murray
- Re: [Xen-devel] Re: Next steps with pv_ops for Xen, Jeremy Fitzhardinge
- Re: [Xen-devel] Re: Next steps with pv_ops for Xen, Derek Murray
- Re: [Xen-devel] Re: Next steps with pv_ops for Xen, Ian Main
- Re: [Xen-devel] Re: Next steps with pv_ops for Xen, Gerd Hoffmann
- Re: [Xen-devel] Re: Next steps with pv_ops for Xen, Gerd Hoffmann
- Re: [Xen-devel] Re: Next steps with pv_ops for Xen, Derek Murray
|
|
|