Re: [Xen-devel] (v2) Design proposal for RMRR fix

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: George Dunlap
> Sent: Friday, January 09, 2015 12:00 AM
> 
> >>>>>3.3 Policies
> >> ----
> >> An intuitive thought is to fail immediately upon a confliction, however
> >> it is not flexible regarding to different requirments:
> >>
> >> a) it's not appropriate to fail libxc domain builder just because such
> >> confliction. We still want the guest to boot even w/o assigned device;
> >
> > I don't think that's right (and I believe this was discussed before):
> > When device assignment fails, VM creation should fail too. It is the
> > responsibility of the host admin in that case to remove some or all
> > of the to be assigned devices from the guest config.
> 
> Yes; basically, if we get to domain build time and we haven't reserved
> the RMRRs, then it's a bug in libxl (since it's apparently told Xen
> one thing and libxc another thing).  Having libxc fail in that case is
> a perfectly sensible thing to do.

I'd like a way either throwing warning and then move forward, or just fails 
the device assignment (i.e. not exposing to guest) instead of failing the 
whole guest, to mimic native behavior.

> 
> >> We propose report-all as the simple solution (different from last sent
> >> version which used report-sel), regarding to the below facts:
> >>
> >>   - 'warn' policy in user space makes report-all not harmful
> >>   - 'report-all' still means only a few entries in reality:
> >>     * RMRR reserved regions should be avoided or limited by platform
> >> designers, per VT-d specification;
> >>     * RMRR reserved regions are only a few on real platforms, per our
> >> current observations;
> >
> > Few yes, but in the IGD example you gave the region is quite large,
> > and it would be fairly odd to have all guests have a strange, large
> > hole in their address spaces. Furthermore remember that these
> > holes vary from machine to machine, so a migrateable guest would
> > needlessly end up having a hole potentially not helping subsequent
> > hotplug at all.
> 
> Yes, I think that by default VMs should have no RMRRs set up on domain
> creation.  The only way to get RMRRs in your address space should be
> to opt-in at domain creation time (either by statically assigning
> devices, or by requesting your memory layout to mirror the host's).

ideally yes, but I'm thinking how bad it is to create some unnecessary
holes compared to the complexity of accurate control.

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