Don't allow access to the physical ASLS register. It contains a host
address which is meaningless for the guest. Additionally, it allows the
guest to safely rewrite this register.
This is the last commit required for GVT-d. Nevertheless, it might not
work due to missing firmware support.
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D26209
This makes the OpRegion accessible by the guest. However, the guest
doesn't know the address of the OpRegion. This will be fixed by an
upcoming commit.
The range of the OpRegion is added to the e820 table. This allows the
guest firmware to easily pick up this range and to reserve it properly.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40041
The OpRegion provides some configuration bits and ACPI methods used by
some Intel drivers. The guest needs access to it. In the first step,
we're reading it's address and size.
Reviewed by: jhb
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40040
This register contains a host physical address. This address is
meaningless for the guest. We have to emulate it and set it to a valid
guest physical address.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40060
The graphics stolen memory is only GPU accessible. So, we don't have to
copy any data to it as the guest will be unable to access it anyway. We
just have to allocate and reserve some memory. That's done by adding an
E820 entry for the graphics stolen memory. The guest firmware will pick
up the E820 and reserve this range.
Note that we try to reuse the host address as Intel states that newer
Tiger Lake platforms need this [1].
[1]
e28d6fbfdf/devicemodel/hw/pci/passthrough.c (L626-L629)
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40059
This is the first step to emulate the graphics stolen memory register.
Note that the graphics stolen memory is somehow confusing. On the one
hand the Intel Open Source HD Graphics Programmers' Reference Manual
states that it's only GPU accessible. As the CPU can't access the area,
the guest shouldn't need it. On the other hand, the Intel GOP driver
refuses to work properly, if it's not set to a proper address.
Intel itself maps it into the guest by EPT [1]. At the moment, we're not
aware of any situation where this EPT mapping is required, so we don't
do it yet.
Intel also states that the Windows driver for Tiger Lake reads the
address of the graphics stolen memory [2]. As the GVT-d code doesn't
support Tiger Lake in its first implementation, we can't check how it
behaves. We should keep an eye on it.
[1]
e28d6fbfdf/devicemodel/hw/pci/passthrough.c (L655-L657)
[2]
e28d6fbfdf/devicemodel/hw/pci/passthrough.c (L626-L629)
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40039
Don't emulate anything yet. Just check if the user would like to pass an
Intel GPU to the guest.
Reviewed by: jhb, markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40038
