From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v7][RFC][PATCH 06/13] hvmloader/ram: check if guest memory is out of reserved device memory maps Date: Fri, 31 Oct 2014 13:41:06 +0800 Message-ID: <545320F2.5030103@intel.com> References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com> <1414136077-18599-7-git-send-email-tiejun.chen@intel.com> <544A84B10200007800042016@mail.emea.novell.com> <544DFDB2.2010508@intel.com> <544E29C70200007800042595@mail.emea.novell.com> <544F49F9.3070208@intel.com> <544F78B80200007800042B95@mail.emea.novell.com> <54509A8A.9060606@intel.com> <5450BE27020000780004304A@mail.emea.novell.com> <5451AC56.7010303@intel.com> <54521100020000780004363A@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: <54521100020000780004363A@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 On 2014/10/30 17:20, Jan Beulich wrote: >>>> On 30.10.14 at 04:11, wrote: >> On 2014/10/29 17:15, Jan Beulich wrote: >>>>>> On 29.10.14 at 08:43, wrote: >>>> In VT-D specification, I just see, >>>> >>>> "The RMRR regions are expected to be used for legacy usages (such as >>>> USB, UMA Graphics, etc.) requiring reserved memory. Platform designers >>>> should avoid or limit use of reserved memory regions since these require >>>> system software to create holes in the DMA virtual address range >>>> available to system software and its driver." >>> >>> Nice that you quote it, but did you also read it properly? There's this >>> little "etc" following the explicit naming of USB and UMA... >> >> Yes. But this already clarify RMRR "used for legacy usage" and "avoid or >> limit use of reserved memory regions", so RMRR would be gone finally. So >> I mean it may be acceptable to assume something based our known info. > > No. Making assumption on observed broken behavior is okay (to work > around it), but making assumptions for not (yet) observed correct > behavior to be absent should never be done. > >>>>> In the tool stack, don't even populate these holes with RAM. This >>>>> will then lead to RAM getting populated further up at the upper end. >>>> >>>> Shouldn't populate RAM still with guest_physmap_add_entry()? If yes, we >>>> already be there to mark them as p2m_access_n. >>> >>> Marking them with p2m_access_n is not the same as not populating >>> the regions in the first place. Again - hiding multiple megabytes of >>> memory (and who knows if it can't grow into the gigabyte range) is >>> just not acceptable. Even for just a few pages I wouldn't be really >> >> I don't think so. If you're considering a VM, this case should be same >> under native circumstance. And in native case, all RMRR ranges are >> marked as reserved in e820 table. > > That would only be a valid comparison if all devices associated with > RMRRs would also be passed to that particular VM. But since you're > doing the E820 adjustment to all VMs (no matter whether they would > ever get _any_ device passed through to them) this is not comparing > like entities. > > Thinking about this some more, this odd universal hole punching in > the E820 is very likely to end up causing problems. Hence I think > this really should be optional behavior, with pass through of devices > associated with RMRRs failing if not used. (This ought to include > punching holes for _just_ the devices passed through to a guest > upon creation when the option is not enabled.) Yeah, we had a similar discussion internal to add a parameter to force reserving RMRR. In this case we can't create a VM if these ranges conflict with anything. So what about this idea? If yes, could you give us some rules we should follow? Thanks Tiejun