This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [PATCH] let set_phys_to_machine return the old entry

To: Stefan Berger <stefanb@xxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] let set_phys_to_machine return the old entry
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 20 Apr 2006 20:08:08 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 20 Apr 2006 12:12:04 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1145558053.10850.6.camel@xxxxxxxxxxxxxxxxxxxxx>
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: <1145558053.10850.6.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 20 Apr 2006, at 19:34, Stefan Berger wrote:

The attached patch makes set_phys_to_machine(pfn,mfn) return the old
entry in the array, such that the old entry can be restored again using
the same call. If the feature XENFEAT_auto_translate_physmap is not
enabled, then these two calls will end up in no-op relative to changes
to the phys_to_machine_mapping array.

There's currently only one occurrence where remembering the entry from
the array is necessary and this is in the vTPM backend driver.

This patch builds on top of the previously posted TPM backend patch.

Why do you need to mess with the phys_to_machine table at all? You install the mapping only for a very short time, to do a memcpy or copy_from_user: neither of which will use that p2m entry. Even if you really do want to set the p2m entry properly you know that its old value must be INVALID_P2M_ENTRY because you obtained that kernel virtual address via balloon_alloc_empty_page_range().

You should probably just delete the p2m code from that copy routine.

 -- Keir

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>