[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 |