Re: git: 6171e026be11 - main - bhyve: add support for MTRR

On Tue, Jan 18, 2022 at 07:19:15AM -0800, John Baldwin wrote:
> On 1/14/22 3:42 AM, Emmanuel Vadot wrote:
> > The branch main has been updated by manu:
> > 
> > URL: https://cgit.FreeBSD.org/src/commit/?id=6171e026be11824495cebe8baf559af673a8e533
> > 
> > commit 6171e026be11824495cebe8baf559af673a8e533
> > Author:     Corvin Köhne <CorvinK@beckhoff.com>
> > AuthorDate: 2022-01-14 09:58:48 +0000
> > Commit:     Emmanuel Vadot <manu@FreeBSD.org>
> > CommitDate: 2022-01-14 11:41:44 +0000
> > 
> >      bhyve: add support for MTRR
> >      Some guests or driver might depend on MTRR to work properly. E.g. the
> >      nvidia gpu driver won't work without MTRR.
> >      Reviewed by:    markj
> >      MFC after:      2 weeks
> >      Sponsored by:   Beckhoff Automation GmbH & Co. KG
> >      Differential Revision:  https://reviews.freebsd.org/D33333
> 
> So this doesn't look like actual emulation, but more like a dummy version?
> That is, the values aren't initialized to the "normal" state (WB for guest RAM,
> UC- for everything else), and the state isn't enforced in any way (I think the
> only sane way to actually implement these would be to use MTRR to set PAT values
> in EPT entries if EPT even supports PAT).  Perhaps this mostly doesn't matter
> since we don't directly map BARs in EPT anyway?  (Though perhaps for passthrough
> we might in which case you'd want to honor these settings in those?)
> 
I do not believe that it is safe to enable actual application of the cache
modes set by guest, to the EPT pages. At very least, there are a lot of
erratas claiming broken situations like inconsistent mappings modes causing
machine checks or reboots on Intel processors.

Or, it should be only enabled for specific trusted vms.  For passthough,
I think we only need to set proper mode for BARs in EPT in advance.