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: Thu, 30 Oct 2014 11:11:18 +0800 Message-ID: <5451AC56.7010303@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5450BE27020000780004304A@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/29 17:15, Jan Beulich wrote: >>>> On 29.10.14 at 08:43, wrote: >> On 2014/10/28 18:06, Jan Beulich wrote: >>>>>> On 28.10.14 at 08:47, wrote: >>>> On 2014/10/27 18:17, Jan Beulich wrote: >>>>>>>> On 27.10.14 at 09:09, wrote: >>>>>> On 2014/10/24 22:56, Jan Beulich wrote: >>>>> _no matter_ what RMRRs a physical host has, it should not prevent >>>>> the creation of guests (the worst that may result is that passing >>>>> through certain devices doesn't work anymore, and even then the >>>>> operator needs to be given a way of circumventing this if (s)he >>>>> knows that the device won't access the range post-boot, or if it's >>>>> being deemed acceptable for it to do so). >>>> >>>> As we know just legacy USB and GFX need these RMRR ranges. >>> >>> This is specified where? >> >> 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. > >> RMRR really is very troublesome. >> >> The legacy usage of USB just cover ps2 emulation as I know. And as you >> see these address are different in different platforms so this mean >> they're not redistricted somewhere specific. And GFX need more space so >> its not possible to be placed under 1M. >> >> So maybe I can drop patch #12, xen/vtd: re-enable USB device assignment, >> to leave USB out our scope. Or a little improvement is to check if its >> own range is below 1M. > > I think we made clear a number of iterations ago that rather than > aiming for another half baked solution, it should be done right this > time. No excuses. It's bad enough that this half broken code made > it into the tree originally. Okay. But if USB is really overlapping with BIOS... Furthermore, maybe I can ask some guys to look into if we can move RMRR ranges in the hypervisor. If yes, things could be better. > >>> 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. Thanks Tiejun > happy, but could probably be talked into accepting this. > > Jan > > >