RE: git: 6171e026be11 - main - bhyve: add support for MTRR
- In reply to: Konstantin Belousov : "Re: git: 6171e026be11 - main - bhyve: add support for MTRR"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 19 Jan 2022 07:31:48 UTC
Hi, this commit shouldn't add real MTRR emulation. The nvidia GPU driver requires MTRR to work properly. If MTRR is missing, the driver will fail on startup. Adding a dummy MTRR implementation is sufficient to solve this issue. Best regards Corvin Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff Registered office: Verl, Germany | Register court: Guetersloh HRA 7075 -----Original Message----- From: Konstantin Belousov <kostikbel@gmail.com> Sent: Tuesday, January 18, 2022 5:32 PM To: John Baldwin <jhb@freebsd.org> Cc: Emmanuel Vadot <manu@freebsd.org>; src-committers@freebsd.org; dev-commits-src-all@freebsd.org; dev-commits-src-main@freebsd.org Subject: Re: git: 6171e026be11 - main - bhyve: add support for MTRR CAUTION: External Email!! 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://nospamproxywebp.beckhoff.com/enqsig/link?id=BCAAAABGd7m3lfMOLOIhx3uNR_1Qav4Ffx8-jQB0torD82ts_KYAAABj7YMrJMLJ7cXPyMvbFX9WJKJ3O_9eSEsrjC4dOUoxa4zlBD0VGYmBMUrUqe0J6nLTsxbGabU9mr5yyGtEAvpJO3CAuBBgfol1iNi8mky-rPfp7A4-KzOkZzVVDoTvyV5onuiY7akaRkSHD6_6whenu6bm6k3330UqkbIJnhHHTAH_aCuNdUpRPB21mCqUtWVbmJR0l1ZlmblFbs21-oJr5_5aqmOQ0 > > > > 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://nospamproxywebp.beckhoff.com/enqsig/link?id=BCAAAABGd7m3lfMOLOIhx3uNR_1Qav4Ffx8-jQB0torD82ts_HgAAADXKw6wUJtKFi6JF3K0iUvqHd4jzUMtqPnMIo16BSb3OZ4KOWvJONCUys3_dW62_stIRwAB1O3CWRQezI1ZSyN_mqt7E2_iAJ_f4pJPER5NYObzKaqbtVmN0KRAdilVPRQ_5JGBJM3VaTlUYexq-jay78fOBZtyFBs1 > > 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.