[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 11/14] xen/x86: mm: Re-implement set_gpfn_from_mfn() as a static inline function
Hi, On 10/05/2019 14:48, Jan Beulich wrote: On 10.05.19 at 15:41, <julien.grall@xxxxxxx> wrote:On 10/05/2019 14:35, Jan Beulich wrote:On 10.05.19 at 15:27, <julien.grall@xxxxxxx> wrote:On 10/05/2019 13:43, Jan Beulich wrote:On 07.05.19 at 17:14, <julien.grall@xxxxxxx> wrote:+static inline void set_gpfn_from_mfn(unsigned long mfn, unsigned long pfn) +{ + struct domain *d = page_get_owner(mfn_to_page(_mfn(mfn))); + unsigned long entry = (d && (d == dom_cow)) ? SHARED_M2P_ENTRY : pfn;The && here looks, ehm, funny, but I guess it's needed for early boot?I have no idea, this is x86 not Arm...But that's perhaps a separate thing to clean up. However, looking at this - why is Arm setting up dom_cow in the first place?Common code is using dom_cow, so I don't think we want it to be NULL on Arm to avoid weird issues.I didn't mean it to remain NULL. Common code doesn't dereference it (and isn't supposed to), so I'd consider initializing it to some known faulting non-NULL address, if there is such on Arm.Patches are welcomed ;).So is there such an address on Arm? 0 - 2MB is unmapped so far. I don't know whether this will still be the case (at least for the range 4KB - 2MB) with the rework I am attempting. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |