|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 1/5] x86/p2m: paging_write_p2m_entry() is a private function
On 10.11.2020 11:27, Roger Pau Monné wrote:
> On Wed, Oct 28, 2020 at 10:22:04AM +0100, Jan Beulich wrote:
>> As it gets installed by p2m_pt_init(), it doesn't need to live in
>> paging.c. The function working in terms of l1_pgentry_t even further
>> indicates its non-paging-generic nature. Move it and drop its
>> paging_ prefix, not adding any new one now that it's static.
>>
>> This then also makes more obvious that in the EPT case we wouldn't
>> risk mistakenly calling through the NULL hook pointer.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>
> Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Thanks.
>> --- a/xen/arch/x86/mm/p2m-pt.c
>> +++ b/xen/arch/x86/mm/p2m-pt.c
>> @@ -108,6 +108,31 @@ static unsigned long p2m_type_to_flags(c
>> }
>> }
>>
>> +/*
>> + * Atomically write a P2M entry and update the paging-assistance state
>> + * appropriately.
>> + * Arguments: the domain in question, the GFN whose mapping is being
>> updated,
>> + * a pointer to the entry to be written, the MFN in which the entry resides,
>> + * the new contents of the entry, and the level in the p2m tree at which
>> + * we are writing.
>> + */
>> +static int write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
>> + l1_pgentry_t *p, l1_pgentry_t new,
>> + unsigned int level)
>> +{
>> + struct domain *d = p2m->domain;
>> + struct vcpu *v = current;
>
> I think you could constify both?
For v it looks like I could. For d a subsequent patch would then
need to undo it, so I'd prefer to keep it this way here.
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |