Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if guest memory is out of reserved device memory maps

["Chen, Tiejun" <tiejun.chen@xxxxxxxxx>]

On 2014/10/30 17:20, Jan Beulich wrote:
> > > > On 30.10.14 at 04:11, <tiejun.chen@xxxxxxxxx> wrote:
> > On 2014/10/29 17:15, Jan Beulich wrote:
> > > > > > On 29.10.14 at 08:43, <tiejun.chen@xxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel