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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan



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