From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v6][PATCH 2/2] xen:vtd: missing RMRR mapping while share EPT Date: Thu, 31 Jul 2014 17:45:31 +0800 Message-ID: <53DA103B.4000308@intel.com> References: <1406684186-12788-1-git-send-email-tiejun.chen@intel.com> <1406684186-12788-2-git-send-email-tiejun.chen@intel.com> <53D8CAC402000078000278E9@mail.emea.novell.com> <53D8B408.1010409@intel.com> <53D8D5A0020000780002792A@mail.emea.novell.com> <53D8BD70.7040905@intel.com> <53D8E4370200007800027986@mail.emea.novell.com> <53D8CB80.1000606@intel.com> <53D8E95A02000078000279BD@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53D8E95A02000078000279BD@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 2014/7/30 18:47, Jan Beulich wrote: >>>> On 30.07.14 at 12:40, wrote: >> On 2014/7/30 18:25, Jan Beulich wrote: >>>>>> On 30.07.14 at 11:40, wrote: >>>> From what those codes mean, it just return regardless whether they >>>> really conflict. And this is just a good assumption, so if I'm >>>> understanding this properly, actually our patches do this thing >>>> precisely because we further check if this assumption is true, then take >>>> necessary actions. >>> >>> Except that the pointed out check prevents the code you modify >>> from being reached at all, i.e. as long as that check is there it >>> doesn't matter (for any passed through USB device) what action >>> rmrr_identity_mapping() takes. >>> >> >> Sorry, what do you mean? >> >> From my point of view these two patches should be better than drop >> simply RMRR for any PT USB device no matter if its really necessary. > > I mean that for USB devices your patches change nothing without > said check also getting removed. > Jan, For USB instance, I think currently we still keep that until we have a complete solution since this is always safe. Additionally, I'm trying to figure out that solution. As I mentioned previously, I think we can reserve all RMRR once when a guest call XENMEM_machine_memory_map to create its own memory. What about this idea? Or other better suggestions? Thanks Tiejun