Re: [Xen-devel] [PATCH 5/5] docs/pvh: document initial MTRR state

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.05.18 at 10:30, <roger.pau@xxxxxxxxxx> wrote:
> On Tue, May 15, 2018 at 01:51:03AM -0600, Jan Beulich wrote:
>> >>> On 14.05.18 at 18:18, <wei.liu2@xxxxxxxxxx> wrote:
>> > On Mon, May 14, 2018 at 10:13:47AM -0600, Jan Beulich wrote:
>> >> >>> On 14.05.18 at 18:03, <wei.liu2@xxxxxxxxxx> wrote:
>> >> > On Thu, May 10, 2018 at 06:15:05PM +0100, Roger Pau Monne wrote:
>> >> >> --- a/docs/misc/pvh.markdown
>> >> >> +++ b/docs/misc/pvh.markdown
>> >> >> @@ -92,3 +92,18 @@ event channels. Delivery of those interrupts can be 
> configured in the same way
>> >> >>  as HVM guests, check xen/include/public/hvm/params.h and
>> >> >>  xen/include/public/hvm/hvm\_op.h for more information about available 
> delivery
>> >> >>  methods.
>> >> >> +
>> >> >> +## MTRR ##
>> >> >> +
>> >> >> +### Unprivileged guests ###
>> >> >> +
>> >> >> +PVH guests are booted with the default MTRR type set to write-back 
>> >> >> and 
> MTRR
>> >> >> +enabled. This allows DomUs to start with a sane MTRR state. Note that 
> this will
>> >> >> +have to be revisited when pci-passthrough is added to PVH in order to 
>> >> >> set 
> MMIO
>> >> >> +regions as UC.
>> >> > 
>> >> > My reading is "revisited" implies the default type will change. In fact
>> >> > it shouldn't. We should clarify: for ram it will remain WB, for MMIO
>> >> > holes it will be UC.
>> >> 
>> >> Why would changing the default late be a problem? A firmware update on
>> >> bare hardware might also have such an effect. The default type read from
>> >> the MSR must not change across the lifetime of a VM, but imo may change
>> >> across reboots of it.
>> >> 
>> > 
>> > Then setting a default here doesn't really help OS developers because
>> > they will always need to write code to set the correct type -- not that
>> > this is a big issue, but as I understand it the point here is to avoid
>> > that.
>> 
>> Hmm, my understanding of the purpose of the series was that it aims at
>> establishing some sane (i.e. reasonable for an OS to expect) state, instead
>> of a firm "this will always be this way" one. Furthermore OSes generally
>> shouldn't find a need to fiddle with MTRRs, provided firmware has done a
>> proper job setting them up.
> 
> Indeed that's the purpose. Most OSes don't really care about the
> details of the MTRR setup, and they just expect RAM regions to be set
> to WB and MMIO holes to UC AFAICT.
> 
> I don't think Xen has to provide any guarantee about the details of
> the MTRR state, apart from stating that RAM will be WB and MMIO UC.
> 
> I can leave the text as-is, or add the paragraph suggested in another
> email to clarify if the current writing is prone to misunderstanding.

I indeed think the text as still visible above is not sufficiently clear (as in:
is not leaving sufficient leeway for future adjustments), so I'd prefer if
the clarification from the other sub-thread was used (as replacement or
addition).

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel