From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v7][RFC][PATCH 01/13] xen: RMRR fix Date: Mon, 27 Oct 2014 10:00:42 +0800 Message-ID: <544DA74A.4020505@intel.com> References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com> <544A4B7A0200007800041E0D@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: <544A4B7A0200007800041E0D@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, tim@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org n 2014/10/24 18:52, Jan Beulich wrote: >>>> On 24.10.14 at 09:34, wrote: Thanks for your review. >> 5. Before we take real device assignment, any access to RMRR may issue >> ept_handle_violation because of p2m_access_n. Then we just call >> update_guest_eip() to return. > > I.e. ignore such accesses? Why? Yeah. This illegal access isn't allowed but its enough to ignore that without further protection or punishment. Or what procedure should be concerned here based on your opinion? > >> Now in our case we add a rule: >> - if p2m_access_n is set we also set this mapping. > > Does that not conflict with eventual use mem-access makes of this > type? > In our case, we always initialize these RMRR ranges with p2m_access_n to make sure we can intercept any illegal access to these range until we can reset them with p2m_access_rw via set_identity_p2m_entry(d, base_pfn, p2m_access_rw). Thanks Tiejun