|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 6/7] x86/mm: Combine {destroy, replace}_grant_{pte, va}_mapping()
On 12/09/17 17:32, Wei Liu wrote:
> On Tue, Sep 12, 2017 at 05:30:11PM +0100, Andrew Cooper wrote:
>> On 12/09/17 15:58, Wei Liu wrote:
>>> On Tue, Sep 12, 2017 at 01:14:45PM +0100, Andrew Cooper wrote:
>>>> As with the create side of things, these are largely identical. Most cases
>>>> are actually destroying the mapping rather than replacing it with a stolen
>>>> entry.
>>>>
>>>> Reimplement their logic in replace_grant_pv_mapping() in a mostly common
>>>> way.
>>>>
>>>> No (intended) change in behaviour from a guests point of view.
>>>>
>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
>>>
>>> With two suggestions:
>>>
>>>> int create_grant_pv_mapping(uint64_t addr, unsigned long frame,
>>>> unsigned int flags, unsigned int cache_flags)
>>>> {
>>>> @@ -4136,12 +3959,14 @@ int replace_grant_pv_mapping(uint64_t addr,
>>>> unsigned long frame,
>>>> {
>>>> struct vcpu *curr = current;
>>>> struct domain *currd = curr->domain;
>>>> - l1_pgentry_t ol1e;
>>>> - int rc;
>>>> + l1_pgentry_t nl1e = l1e_empty(), ol1e, *pl1e;
>>>> + struct page_info *page;
>>>> + mfn_t gl1mfn;
>>>> + int rc = GNTST_general_error;
>>>> unsigned int grant_pte_flags = grant_to_pte_flags(flags, 0);
>>>>
>>>> /*
>>>> - * On top of the explicit settings done by create_grant_host_mapping()
>>>> + * On top of the explicit settings done by create_pv_host_mapping()
>>>> * also open-code relevant parts of adjust_guest_l1e(). Don't mirror
>>>> * available and cachability flags, though.
>>>> */
>>>> @@ -4150,24 +3975,96 @@ int replace_grant_pv_mapping(uint64_t addr,
>>>> unsigned long frame,
>>>> ? _PAGE_GLOBAL
>>>> : _PAGE_GUEST_KERNEL | _PAGE_USER;
>>>>
>>>> + /*
>>>> + * addr comes from Xen's active_entry tracking, and was used
>>>> successfully
>>>> + * to create a grant.
>>>> + *
>>>> + * The meaning of addr depends on GNTMAP_contains_pte. It is either a
>>>> + * machine address of an L1e the guest has nominated to be altered,
>>>> or a
>>>> + * linear address we need to look up the appropriate L1e for.
>>>> + *
>>>> + * Passing a new_addr of zero is taken to mean destroy. Passing a
>>>> + * non-zero new_addr has only ever been available via
>>>> + * GNTABOP_unmap_and_replace and only when using linear addresses.
>>>> + */
>>> IMHO this should be moved before the function.
>> Which bit? The addr and GNTMAP_contains_pte need to be here to explain
>> the curious if statement below.
>>
>> The final paragraph only makes sense in the context of the middle paragraph.
> At least the new_addr == 0 means destroying mapping bit.
I've folded the following incremental delta.
~Andrew
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f05a1d7..202eee2 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3958,6 +3958,11 @@ static bool steal_linear_address(unsigned long
linear, l1_pgentry_t *out)
return okay;
}
+/*
+ * Passing a new_addr of zero is taken to mean destroy. Passing a non-zero
+ * new_addr has only ever been available via GNTABOP_unmap_and_replace, and
+ * only when !(flags & GNTMAP_contains_pte).
+ */
int replace_grant_pv_mapping(uint64_t addr, unsigned long frame,
uint64_t new_addr, unsigned int flags)
{
@@ -3986,10 +3991,6 @@ int replace_grant_pv_mapping(uint64_t addr,
unsigned long frame,
* The meaning of addr depends on GNTMAP_contains_pte. It is either a
* machine address of an L1e the guest has nominated to be altered,
or a
* linear address we need to look up the appropriate L1e for.
- *
- * Passing a new_addr of zero is taken to mean destroy. Passing a
- * non-zero new_addr has only ever been available via
- * GNTABOP_unmap_and_replace and only when using linear addresses.
*/
if ( flags & GNTMAP_contains_pte )
{
@@ -3997,6 +3998,7 @@ int replace_grant_pv_mapping(uint64_t addr,
unsigned long frame,
if ( new_addr )
goto out;
+ /* Sanity check that we won't clobber the pagetable. */
if ( !IS_ALIGNED(addr, sizeof(nl1e)) )
{
ASSERT_UNREACHABLE();
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |