[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 29.07.14 at 08:44, <tiejun.chen@xxxxxxxxx> wrote:
> 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.

Yes, I do think we either need to fix this in its entirety, or - as
suggested before - disallow passing through devices associated
with an RMRR. And no, I'm not aware of anyone already looking
into this.

Jan


_______________________________________________
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®.