[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 1/2] x86/mm: factor out the code for shattering an l3 PTE



On 11.12.2019 17:34, Xia, Hongyan wrote:
> On Wed, 2019-12-11 at 16:29 +0100, Jan Beulich wrote:
>>> +    }
>>> +
>>> +    if ( locking )
>>> +        spin_lock(&map_pgdir_lock);
>>> +    if ( (l3e_get_flags(*pl3e) & _PAGE_PRESENT) &&
>>> +         (l3e_get_flags(*pl3e) & _PAGE_PSE) )
>>> +    {
>>> +        l3e_write_atomic(pl3e,
>>> +            l3e_from_paddr((paddr_t)virt_to_maddr(l2t),
>>> __PAGE_HYPERVISOR));
>>
>> Why the cast? (I'm sorry if this was there on v3 already and I
>> didn't spot it. And if this remains the only thing to adjust,
>> then I guess this could be taken care of while committing.)
> 
> Sadly there is no l3e_from_maddr or virt_to_paddr to call directly. Of
> course, paddr_t and maddr have the same underlying type (unsigned
> long), so it works without a cast. I just added the cast to make it
> explicit that these two are not exactly the same.

Yes, there continues to be a naming disconnect. But no, this is
not a reason to add a cast. Casts should be used as sparingly
as possible, since they tend to hide problems.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.