Hi,
On 4/19/20 14:26, Santucco wrote:
> Hello,
> I have found a source of the problem.
> In displ_be, BaseDump copies to the drm buffer with a size from
> i915 drm driver, but this size a bit more than a size of my frontend
> display buffer. I have made a quick and dirty fix, a copy a line of
On 17.04.2020 21:46, Andrew Cooper wrote:
> On 17/04/2020 15:25, Jan Beulich wrote:
>> Drop the NULL checks - they've been introduced by commit 8d7b633ada
>> ("x86/mm: Consolidate all Xen L4 slot writing into
>> init_xen_l4_slots()") for no apparent reason.
>
> :) I'll take this as conformation
> From: Brendan Kerrigan
> Sent: Friday, April 17, 2020 9:36 PM
>
> From: Brendan Kerrigan
>
> The Intel graphics device records DMAR faults regardless
> of the Fault Process Disable bit being set. When this fault
Since this is an errata for specific generations, let's describe
this way
> From: Roger Pau Monne
> Sent: Friday, April 17, 2020 7:30 PM
>
> The EPT page tables can be shared with the IOMMU as long as the page
> sizes supported by EPT are also supported by the IOMMU.
>
> Current code checks that both the IOMMU and EPT support the same page
> sizes, but this is not
From: Julien Grall
The documentation of pvcalls only describes the padding for i386. This
is a bit odd as there are some implicit padding for 64-bit (e.g in
xen_pvcalls_release) and this doesn't cater other 32-bit arch.
Remove the #ifdef in the documentation to show the padding is present on
In commit 0dfffe01d5 "x86: Improve the efficiency of
domain_relinquish_resources()", the x86 version of the function has been
reworked to avoid open-coding the state machine and also add more
documentation.
Bring the Arm version on part with x86 by introducing a documented
PROGRESS() macro to
