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

Re: [Xen-devel] [v4][PATCH 1/2] xen:x86:mm:p2m: introduce set_rmrr_p2m_entry



On 2014/7/28 20:07, Jan Beulich wrote:
On 28.07.14 at 13:42, <tiejun.chen@xxxxxxxxx> wrote:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -858,6 +858,32 @@ int set_mmio_p2m_entry(struct domain *d, unsigned long 
gfn, mfn_t mfn)
      return set_typed_p2m_entry(d, gfn, mfn, p2m_mmio_direct);
  }

+int set_rmrr_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)

Leaving aside all the previously raised points making me hesitate to
accept the pair of patches on their own, let's please try to avoid

Do you mean we should fix such RMRR problem completely? Looks we need to reserve the RMRR range for each VM. So I'm considering to force reserving this range when we go that XENMEM_machine_memory_map for each VM. But I'm not sure if this is good. So maybe we can do this after this thread since I guess myself need some time to investigate this problem. Or you know this is ongoing by some guys, I'd like to refine my patches to follow that.

having Intel specific function names in non-Intel-specific code unless
that's really the best choice. In the case here, you could
s/rmrr/identity/ and at once drop the redundant mfn argument (the
function can construct this for the call to p2m_set_entry(), and the
function name will make it obvious why this gets derived from gfn).


Okay.

Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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