[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set p2m_access_n for reserved device memory mapping
>>> On 04.11.14 at 11:41, <tiejun.chen@xxxxxxxxx> wrote: > On 2014/11/4 16:02, Jan Beulich wrote: >>>>> On 04.11.14 at 02:35, <tiejun.chen@xxxxxxxxx> wrote: >>> @@ -686,8 +686,25 @@ guest_physmap_add_entry(struct domain *d, unsigned >>> long gfn, >>> /* Now, actually do the two-way mapping */ >>> if ( mfn_valid(_mfn(mfn)) ) >>> { >>> - rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t, >>> - p2m->default_access); >>> + rc = 0; >>> + a = p2m->default_access; >>> + if ( !is_hardware_domain(d) ) >>> + { >>> + rc = >>> iommu_get_reserved_device_memory(p2m_check_reserved_device_memory, >>> + &gfn); >>> + /* We always avoid populating reserved device memory. */ >>> + if ( rc == 1 ) >>> + goto out; >> >> But you'll need to make sure that you don't return 1 to the callers: > > You're right. > >> They expect 0 or negative error codes. But with the model of >> not even populating these regions (or relocating the memory >> before [at boot time] assigning a device associated with an RMRR) >> I think this needs to become an error anyway. > > Looks -EINVAL might be used. Hmm, -EINVAL is being used way too frequently already. -EBUSY would make it at least a little bit more distinct. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |