From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v7][RFC][PATCH 01/13] xen: RMRR fix Date: Wed, 29 Oct 2014 10:51:53 +0800 Message-ID: <54505649.1000103@intel.com> References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com> <544A4B7A0200007800041E0D@mail.emea.novell.com> <544DA74A.4020505@intel.com> <544E214F020000780004253D@mail.emea.novell.com> <544F5570.5050106@intel.com> <544F71270200007800042B51@mail.emea.novell.com> <5450395A.2080703@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5450395A.2080703@intel.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 On 2014/10/29 8:48, Chen, Tiejun wrote: > On 2014/10/28 17:34, Jan Beulich wrote: >>>>> On 28.10.14 at 09:36, wrote: >>> On 2014/10/27 17:41, Jan Beulich wrote: >>>>>>> On 27.10.14 at 03:00, wrote: >>>>> n 2014/10/24 18:52, Jan Beulich wrote: >>>>>>>>> On 24.10.14 at 09:34, wrote: >>>>>>> 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? >>>> >>>> If the access is illegal, inject a fault to the guest or kill it, >>>> unless you >>> >>> Kill means we will crash domain? Seems its radical, isn't it? So I guess >>> its better to inject a fault. >>> >>> But what kind of fault you prefer currently? >> >> #GP (but this being arbitrary is why simply killing the guest is another >> option to consider). > > In this case I think we just need to refer to native behavior. So I feel > GP may be a little bit reasonable. > >> >>>>>>> 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? >>> >>> Do you mean what will happen after we reset these ranges as >>> p2m_access_rw? We already reserve these ranges guest shouldn't access >>> these range actually. And a guest still maliciously access them, that >>> device may not work well. >> >> mem-access is functionality used by a control domain, not the domain > > I really don't know this mechanism so thanks for your good coverage. > >> itself. You need to make sure that neither your use of p2m_access_n >> can confuse the mem-access code, nor that their use can confuse you. > > Absolutely, but I think I need to know more about mem-access firstly. > I think these reserved device memory shouldn't be pocked since any write may affect device. Even, what if a device with RMRR isn't assign current domain? And read also should not be allowed since this still may introduce some potential unexpected behavior to device. So if mem_access is trying to access those RMRR range, could we let mem_access exit directly with some message? I mean we can check if we're accessing those RMRR ranges in case of XENMEM_access_op_set_access. Thanks Tiejun