On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
> Without picking CONFIG_HAS_DEVICE_TREE.
>
> In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset
> of the common/device-tree/ directory. x86 doesn't want dom0less-build.c,
> as that's tightly integrated still to the ARM way of building
On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
> ... without CONFIG_HAS_DEVICE_TREE
>
> Signed-off-by: Alejandro Vallejo
Reviewed-by: Stefano Stabellini
> ---
> xen/common/Kconfig | 1 +
> xen/common/Makefile | 2 +-
> xen/common/device-tree/Makefile | 8
> 3
On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
> ... which means, device-tree.c stops requiring strictly CONFIG_HAS_DEVICE_TREE
> and may function without it.
>
> Not a functional change on architectures that currently use these files,
> as they already select CONFIG_HAS_DEVICE_TREE.
>
> Signed-of
On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of
> bootinfo to a separate file for x86 to take.
>
> With this, bootfdt.h can be cleanly included from x86. A later patch
> extracts the definitions so the functions may be called
On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
> Part of an unpicking process to extract bootfdt contents independent of
> bootinfo
> to a separate file for x86 to take.
>
> Move functions required for early FDT parsing from device_tree.h and arm's
> setup.h onto bootfdt.h
>
> Declaration motion
On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
> Add the single arch-specific field in an "arch" subfield defined in
> asm/bootfdt.h.
>
> No functional change intended.
>
> Signed-off-by: Alejandro Vallejo
>
> ---
> v3:
> * Avoid the bootdomain/boot_domain renames.
> ---
> xen/arch/x86/include
On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
> Create a struct header within kernel_info with the contents common to
> kernel_info and boot_domain, and define that header in common code. This
> enables
> x86 to use that header as-is and drop x86's boot_domain.
>
> Not a functional change.
>
> S
On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
> These types resemble each other very closely in layout and intent,
> and with "struct boot_module" already in common code it makes perfect
> sense to merge them. In order to do so, add an arch-specific area for
> x86-specific tidbits, and rename ident
On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
> ... in alignment with the new coding style on word splitting for type
> names.
>
> This aligns its name with the largely duplicate boot_module struct
> in x86. While there's no equivalent to "struct bootmodules" in x86,
> changing one and not the oth
On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
> There's the unwritten convention in x86 of splitting type names using
> underscores. Add such convention to the CODINNG_STYLE to make it
^ CODING_STYLE
> common and less unwritten.
>
> Signed-off-by: Alejand
On Fri, 13 Jun 2025, Alejandro Vallejo wrote:
> The way they currently include each other, with one of the includes
> being conditional on CONFIG_GRANT_TABLE, makes it hard to know which
> contents are included when.
>
> Break the cycle by removing the asm/grant_table.h include.
>
> Not a functio
On Fri, 13 Jun 2025, Demi Marie Obenour wrote:
> On 6/13/25 18:47, Stefano Stabellini wrote:
> > On Wed, 11 Jun 2025, Jan Beulich wrote:
> >> On 11.06.2025 00:57, Jason Andryuk wrote:
> >>> To add more flexibility in system configuration add the new
> >>> DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCT
On 6/13/25 18:47, Stefano Stabellini wrote:
> On Wed, 11 Jun 2025, Jan Beulich wrote:
>> On 11.06.2025 00:57, Jason Andryuk wrote:
>>> To add more flexibility in system configuration add the new
>>> DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCTL_CDF_device_model.
>>>
>>> Thie new flag corresponds to
On Thu, 12 Jun 2025, Jan Beulich wrote:
> On 11.06.2025 07:08, Jason Andryuk wrote:
> > On 2025-06-11 09:28, Jan Beulich wrote:
> >> On 11.06.2025 00:57, Jason Andryuk wrote:
> >>> Theses are the broad changes needed for a split hardware / control
> >>> domain.
> >>>
> >>> An earlier posting gave d
On Wed, 11 Jun 2025, Jason Andryuk wrote:
> On 2025-06-11 09:27, Jan Beulich wrote:
> > On 11.06.2025 00:57, Jason Andryuk wrote:
> > > Allow the hwdom to access the console, and to access physical
> > > information about the system.
> > >
> > > xenconsoled can read Xen's dmesg. If it's in hwdom,
On Wed, 11 Jun 2025, Jan Beulich wrote:
> On 11.06.2025 00:57, Jason Andryuk wrote:
> > To add more flexibility in system configuration add the new
> > DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCTL_CDF_device_model.
> >
> > Thie new flag corresponds to allowing XSM_DM_PRIV for the domain. This
> >
On Thu, Jun 05, 2025 at 10:43:10AM -0700, ross.philip...@oracle.com wrote:
> > +static void send_cmd(unsigned loc, uint8_t *buf, unsigned i_size,
> > + unsigned *o_size)
> > +{
> > +/*
> > + * Value of "data available" bit counts only when "valid" field is set
> > as
>
On Tue, Jun 03, 2025 at 12:43:30PM -0700, ross.philip...@oracle.com wrote:
> On 5/30/25 6:17 AM, Sergii Dmytruk wrote:
> > From: Krystian Hebel
> >
> > In preparation for TXT SENTER call, GRUB had to modify MTRR settings
> > to be UC for everything except SINIT ACM. Old values are restored
> > fro
On Fri, 6 Jun 2025, Jan Beulich wrote:
> > But the argument I'm going to make this this: Why do you want a check,
> > even if you can find a correct one (and as said before, I cannot)?
> >
> > This function is run exactly once. We've excluded "nothing given by the
> > toolchain", and excluded "w
On 10/06/2025 9:01 am, Jan Beulich wrote:
> On 06.06.2025 17:01, Andrew Cooper wrote:
>> On 06/06/2025 8:22 am, Jan Beulich wrote:
>>> On 05.06.2025 19:01, Andrew Cooper wrote:
On 05/06/2025 2:24 pm, Jan Beulich wrote:
> On 05.06.2025 14:14, Andrew Cooper wrote:
>> On 05/06/2025 1:02 p
On Fri, 13 Jun 2025, Marek Marczykowski-Górecki wrote:
> On Fri, Jun 13, 2025 at 08:35:26AM +0200, Jan Beulich wrote:
> > On 12.06.2025 23:32, Stefano Stabellini wrote:
> > > On Thu, 12 Jun 2025, Andrew Cooper wrote:
> > >> +Support in Xen
> > >> +--
> > >> +
> > >> +There are multiple
On 13/06/2025 4:56 pm, Oleksii Kurochko wrote:
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index e566a18747..c134868e95 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -785,6 +785,20 @@ static int sanitise_domain_config(struct
> xen_domctl_createdomain *config)
>
On 13/06/2025 4:56 pm, Oleksii Kurochko wrote:
> To align with other architectures where is included from
>
> (and not the other way around), the following changes are made:
> - Since is no longer included in :
> - Move the definitions of paddr_to_pte() and pte_to_paddr() to ,
> as paddr_
Hi Ayan
On Fri, Jun 13, 2025 at 5:36 PM Ayan Kumar Halder wrote:
>
> Hi Mykola,
>
> On 06/06/2025 11:11, Mykola Kvach wrote:
> > CAUTION: This message has originated from an External Source. Please use
> > proper judgment and caution when opening attachments, clicking links, or
> > responding t
Hi Ayan
On Fri, Jun 13, 2025 at 5:44 PM Ayan Kumar Halder wrote:
>
> Hi Mykola,
>
> On 02/06/2025 10:04, Mykola Kvach wrote:
> > CAUTION: This message has originated from an External Source. Please use
> > proper judgment and caution when opening attachments, clicking links, or
> > responding t
Hi Ayan,
> On 11 Jun 2025, at 15:35, Ayan Kumar Halder wrote:
>
> Define prepare_selector(), read_protection_region() and
> write_protection_region() for arm32. Also, define
> GENERATE_{READ/WRITE}_PR_REG_OTHERS to access MPU regions from 32 to 255.
>
> Enable pr_{get/set}_{base/limit}(), regio
x86 has specific requirements about the allocation of the domain structure,
but that's not the case for ARM or likely other architectures.
Introduce a generic weak function that can be overwritten with an
architecture specific implementation if required.
RISC-V has a compilation issue [1] after a
From: Roger Pau Monne
x86 has specific requirements about the allocation of the domain structure,
but that's not the case for ARM or likely other architectures.
Introduce a generic weak function that can be overwritten with an
architecture specific implementation if required.
No functional chan
To align with other architectures where is included from
(and not the other way around), the following changes are made:
- Since is no longer included in :
- Move the definitions of paddr_to_pte() and pte_to_paddr() to ,
as paddr_to_pfn() and pte_to_paddr() are already defined there.
- M
Introduce support for IRQ setup on RISC-V by implementing setup_irq() and
__setup_irq(), adapted and extended from an initial implementation by [1].
__setup_irq() does the following:
- Sets up an IRQ action.
- Validates that shared IRQs have non-NULL `dev_id` and are only used when
existin
Introduce interrupt controller descriptor for host APLIC to describe
the low-lovel hardare. It includes implementation of the following functions:
- aplic_irq_startup()
- aplic_irq_enable()
- aplic_irq_disable()
- aplic_set_irq_affinity()
As APLIC is used in MSI mode it requires to enable/disa
The patch series introduces basic UART support (in interrupt mode) and support
of
interrupts for hypervisor mode.
To implement this the following has been added:
- APLIC and IMISC initialization.
- Introduce of intc_hw_operations abstraction.
- Introduce some APLIC and IMSIC operations.
- Introdu
Introduce the intc_hw_operations structure to encapsulate interrupt
controller-specific data and operations. This structure includes:
- A pointer to interrupt controller information (`intc_info`)
- Callbacks to initialize the controller and set IRQ type/priority
- A reference to an interupt control
From: Rahul Singh
Setting CONFIG_PCI_PASSTHROUGH=y will enable PCI passthrough on ARM,
even though the feature is not yet complete in the current upstream
codebase. The purpose of this is to make it easier to enable the
necessary configs (HAS_PCI, HAS_VPCI) for testing and development of PCI
pass
aplic_init() function does the following few things:
- checks that IMSIC in device tree node ( by checking msi-parent property
in APLIC node ) is present as current one implmenetaion of AIA is
supported only MSI method.
- initialize IMSIC based on IMSIC device tree node
- Read value of AP
Update Kconfig to select GENERIC_UART_INIT for basic UART init ( find a dt node
and call device specific device_init() ).
Drop `default n if RISCV` statement for config HAS_NS16550 as now ns16550 is
ready to be compiled and used by RISC-V. Also, make the config user selectable
for everyone except
Implement functions necessarry to have working external interrupts in
hypervisor mode. The following changes are done:
- Add a common function intc_handle_external_irq() to call APLIC specific
function to handle an interrupt.
- Update do_trap() function to handle IRQ_S_EXT case; add the che
Introduce intc_init() to initialize the interrupt controller using the
registered hardware ops.
Also add intc_route_irq_to_xen() to route IRQs to Xen, with support for
setting IRQ type and priority via new internal helpers intc_set_irq_type()
and intc_set_irq_priority().
Call intc_init() to do bas
imsic_init() is introduced to parse device tree node, which has the following
bindings [2], and based on the parsed information update IMSIC configuration
which is stored in imsic_cfg.
The following helpers are introduces for imsic_init() usage:
- imsic_parse_node() parses IMSIC node from DTS
Implements dt_processor_hartid() to get the hart ID of the given
device tree node and do some checks if CPU is available and given device
tree node has proper riscv,isa property.
As a helper function dt_get_hartid() is introduced to deal specifically
with reg propery of a CPU device node.
Signed-
Hi Ayan,
> On 11 Jun 2025, at 15:35, Ayan Kumar Halder wrote:
>
> Modify Arm32 assembly boot code to reset any unused MPU region, initialise
> 'max_mpu_regions' with the number of supported MPU regions and set/clear the
> bitmap 'xen_mpumap_mask' used to track the enabled regions.
>
> Introduce
Hi Ayan,
> On 11 Jun 2025, at 15:35, Ayan Kumar Halder wrote:
>
> Introduce pr_t typedef which is a structure having the prbar and prlar
> members,
> each being structured as the registers of the AArch32 Armv8-R architecture.
>
> Also, define MPU_REGION_RES0 to 0 as there are no reserved 0 bit
Bah, ought to be 00/14. Missed during copy.
Cheers,
Alejandro
Without picking CONFIG_HAS_DEVICE_TREE.
In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset
of the common/device-tree/ directory. x86 doesn't want dom0less-build.c,
as that's tightly integrated still to the ARM way of building domains.
Requires "unsupported" for the time being unti
This file will eventually contain bootfdt helpers that make heavy use of
bootinfo. To simplify git history do the rename here explicitly. A later
patch extracts bootinfo-independent helpers into bootfdt.c.
Doing so here would needlessly pollute the diffs.
Not a functional change.
Signed-off-by:
... without CONFIG_HAS_DEVICE_TREE
Signed-off-by: Alejandro Vallejo
---
xen/common/Kconfig | 1 +
xen/common/Makefile | 2 +-
xen/common/device-tree/Makefile | 8
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/xen/common/Kconfig b/xen/common/Kcon
This will be required later by x86 code in order to do early identification
of boot modules when booting off a DTB.
Not a functional change.
Signed-off-by: Alejandro Vallejo
Reviewed-by: Stefano Stabellini
---
xen/common/device-tree/bootfdt.c | 18 ++
xen/common/device-tre
... which means, device-tree.c stops requiring strictly CONFIG_HAS_DEVICE_TREE
and may function without it.
Not a functional change on architectures that currently use these files,
as they already select CONFIG_HAS_DEVICE_TREE.
Signed-off-by: Alejandro Vallejo
---
xen/common/device-tree/device-
Part of an unpicking process to extract bootfdt contents independent of bootinfo
to a separate file for x86 to take.
Move functions required for early FDT parsing from device_tree.h and arm's
setup.h onto bootfdt.h
Declaration motion only. Not a functional change.
Signed-off-by: Alejandro Vallej
Part of an unpicking process to extract bootfdt contents independent of
bootinfo to a separate file for x86 to take.
With this, bootfdt.h can be cleanly included from x86. A later patch
extracts the definitions so the functions may be called too.
Not a functional change.
Signed-off-by: Alejandro
A later patch removes boot_module and replaces its uses with bootmodule.
The equivalent field for "type" doesn't have BOOTMOD_UNKNOWN as a zero
value, so it must be explicitly set in the static xen_boot_info.
Not a functional change.
Signed-off-by: Alejandro Vallejo
Reviewed-by: Stefano Stabelli
Create a struct header within kernel_info with the contents common to
kernel_info and boot_domain, and define that header in common code. This enables
x86 to use that header as-is and drop x86's boot_domain.
Not a functional change.
Signed-off-by: Alejandro Vallejo
---
v3:
* s/bootdomain/boot_
Add the single arch-specific field in an "arch" subfield defined in
asm/bootfdt.h.
No functional change intended.
Signed-off-by: Alejandro Vallejo
---
v3:
* Avoid the bootdomain/boot_domain renames.
---
xen/arch/x86/include/asm/boot-domain.h | 33 --
xen/arch/x86/inclu
Hi,
New summary when compared to v2:
* Patches 1 and 2 are just cleanup
* Patch 3 is a modification of the CODING_STYLE to reflect the unwritten rule
of splitting type names in words.
* Patch 4 is a rename of struct bootmodule{,s} to boot_module{,s}, in
accordance
to the modificati
... in alignment with the new coding style on word splitting for type
names.
This aligns its name with the largely duplicate boot_module struct
in x86. While there's no equivalent to "struct bootmodules" in x86,
changing one and not the other is just confusing. Same with various
comments and funct
These types resemble each other very closely in layout and intent,
and with "struct boot_module" already in common code it makes perfect
sense to merge them. In order to do so, add an arch-specific area for
x86-specific tidbits, and rename identical fields with conflicting
names.
No functional cha
There's the unwritten convention in x86 of splitting type names using
underscores. Add such convention to the CODINNG_STYLE to make it
common and less unwritten.
Signed-off-by: Alejandro Vallejo
---
CODING_STYLE | 3 +++
1 file changed, 3 insertions(+)
diff --git a/CODING_STYLE b/CODING_STYLE
i
The way they currently include each other, with one of the includes
being conditional on CONFIG_GRANT_TABLE, makes it hard to know which
contents are included when.
Break the cycle by removing the asm/grant_table.h include.
Not a functional change because.
Signed-off-by: Alejandro Vallejo
---
v
Hi Ayan,
> On 11 Jun 2025, at 15:35, Ayan Kumar Halder wrote:
>
> prepare_selector(), read_protection_region() and write_protection_region()
> differ significantly between arm32 and arm64. Thus, move these functions
> to their specific folders.
^— NIT: “to sub-arch specific folder”? What do
Hi Mykola,
On 06/06/2025 11:11, Mykola Kvach wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
From: Volodymyr Babchuk
The changes have been tested only on the R
Hi Mykola,
On 02/06/2025 10:04, Mykola Kvach wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
From: Mirela Simonovic
Timer interrupts must be disabled while the
On Fri, Jun 13, 2025 at 08:35:26AM +0200, Jan Beulich wrote:
> On 12.06.2025 23:32, Stefano Stabellini wrote:
> > On Thu, 12 Jun 2025, Andrew Cooper wrote:
> >> +Support in Xen
> >> +--
> >> +
> >> +There are multiple ways to achieve this security goal, with differing
> >> +tradeoffs fo
On Fri, Jun 13, 2025 at 01:00:09PM +0200, Roger Pau Monne wrote:
> The Xen platform PCI device (vendor ID 0x5853) exposed to x86 HVM guests
> doesn't have the functionality of a traditional PCI device. The exposed
> MMIO BAR is used by some guests (including Linux) as a safe place to map
> foreign
The Xen platform PCI device (vendor ID 0x5853) exposed to x86 HVM guests
doesn't have the functionality of a traditional PCI device. The exposed
MMIO BAR is used by some guests (including Linux) as a safe place to map
foreign memory, including the grant table itself.
Traditionally BARs from devic
On 13.06.2025 12:12, Frediano Ziglio wrote:
> Just code style change.
>
> Signed-off-by: Frediano Ziglio
> ---
> xen/include/xen/pci.h | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
Aiui Eclair will object to declarations now (again?) going out of sync with
On Fri, Jun 13, 2025 at 11:12:47AM +0100, Frediano Ziglio wrote:
> Just code style change.
>
> Signed-off-by: Frediano Ziglio
> ---
> xen/include/xen/pci.h | 26 +-
I think if you change the types of the declarations in pci.h you
should also change the types of the defini
On 13.06.2025 12:13, Frediano Ziglio wrote:
> The comment is similar to extended capabilities in the function
> below.
>
> Signed-off-by: Frediano Ziglio
Acked-by: Jan Beulich
On Thu, Jun 12, 2025 at 07:36:09PM +0200, Alexander Gordeev wrote:
> As a follow-up to commit 691ee97e1a9d ("mm: fix lazy mmu docs and
> usage") take a step forward and protect with a lock not only user,
> but also kernel mappings before entering the lazy MMU mode. With
> that the semantics of arch
Just code style change.
Signed-off-by: Frediano Ziglio
---
xen/include/xen/pci.h | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index ef60196653..f22bbc2776 100644
--- a/xen/include/xen/pci.h
+++ b/xe
The comment is similar to extended capabilities in the function
below.
Signed-off-by: Frediano Ziglio
---
xen/drivers/pci/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/pci/pci.c b/xen/drivers/pci/pci.c
index acf4cebe42..e1ddde90eb 100644
--- a/xen/drivers/
On 07.05.25 14:58, Juergen Gross wrote:
Ping?
I'd really appreciate some feedback.
Juergen
On 21.03.25 10:24, Juergen Gross wrote:
Add basic kexec support to Mini-OS for running in x86 PVH mode.
With this series applied it is possible to activate another kernel
from within Mini-OS.
Righ
On 11/06/2025 15:35, Ayan Kumar Halder wrote:
Define prepare_selector(), read_protection_region() and
write_protection_region() for arm32. Also, define
GENERATE_{READ/WRITE}_PR_REG_OTHERS to access MPU regions from 32 to 255.
Enable pr_{get/set}_{base/limit}(), region_is_valid() for arm32.
Ena
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 256.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Lyude Paul
Cc: Karol Herbst
Cc: Lyude Paul
Cc: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_display.c | 7 ---
1 fi
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.
Signed-off-by: Thomas Zimmermann
Cc: Chun-Kuang Hu
Cc: Philipp Zabel
Cc: Matthias Brugger
Cc: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_gem.c | 13 --
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 4.
Signed-off-by: Thomas Zimmermann
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: Gurchetan Singh
Cc: Chia-I Wu
---
drivers/gpu/drm/virtio/virtgpu_gem.c | 11 +--
1 file changed
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. Align the pitch to a multiple of 8. Align the
buffer size according to hardware requirements.
Xe's internal calculation allowed for 64-bit wide buffer sizes, but
the ioctl's internal checks always verified against 32-
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.
Signed-off-by: Thomas Zimmermann
Cc: Laurent Pinchart
Cc: Kieran Bingham
---
drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 7 +--
1 file changed, 5 inserti
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. Align the pitch to a multiple of 8.
Signed-off-by: Thomas Zimmermann
Cc: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/dr
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 64.
Signed-off-by: Thomas Zimmermann
Acked-by: Heiko Stuebner
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: Andy Yan
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 12 ++--
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. No alignment required.
Signed-off-by: Thomas Zimmermann
Cc: Dave Airlie
Cc: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_dumb.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/dr
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. Alignment is specified in bytes, but the hardware
requires the scanline pitch to be a multiple of 32 pixels. Therefore
compute the byte size of 32 pixels in the given color mode and align
the pitch accordingly. This re
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.
Signed-off-by: Thomas Zimmermann
Acked-by: Thierry Reding
Cc: Thierry Reding
Cc: Mikko Perttunen
---
drivers/gpu/drm/tegra/gem.c | 8 +---
1 file changed, 5
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. No alignment required.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Zack Rusin
Cc: Zack Rusin
Cc: Broadcom internal kernel review list
---
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 21 -
1 fi
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.
Signed-off-by: Thomas Zimmermann
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
---
drivers/gpu/drm/xlnx/zynqmp_kms.c | 7 +--
1 file changed, 5 insertions(+), 2 de
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sui Jingfeng
Cc: Sui Jingfeng
---
drivers/gpu/drm/loongson/lsdc_gem.c | 29 -
1 file ch
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. The hardware requires the framebuffer width to be a
multiple of 8. The scanline pitch has to be large enough to support
this. Therefore compute the byte size of 8 pixels in the given color
mode and align the pitch acco
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 128.
v4:
- align pitch to 128 bytes (Russell)
Signed-off-by: Thomas Zimmermann
Cc: Russell King
---
drivers/gpu/drm/armada/armada_gem.c | 16 +++-
1 file changed, 7 ins
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 128.
The hibmc driver's new hibmc_dumb_create() is similar to the one
in GEM VRAM helpers. The driver was the only caller of
drm_gem_vram_fill_create_dumb(). Remove the now unused help
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.
v5:
- include dumb-buffers header for drm_mode_size_dumb() (kernel test robot)
Signed-off-by: Thomas Zimmermann
Cc: Biju Das
---
drivers/gpu/drm/renesas/rz-du/rz
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. No alignment required.
Signed-off-by: Thomas Zimmermann
Cc: Inki Dae
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Krzysztof Kozlowski
Cc: Alim Akhtar
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 8 +---
1 file
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/d
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 64.
Signed-off-by: Thomas Zimmermann
Cc: Patrik Jakobsson
---
drivers/gpu/drm/gma500/gem.c | 21 ++---
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Tomi Valkeinen
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 15 +++
1 file changed, 7 insertions(+), 8 d
Dumb-buffer pitch and size is specified by width, height, bits-per-pixel
plus various hardware-specific alignments. The calculation of these
values is inconsistent and duplicated among drivers. The results for
formats with bpp < 8 are sometimes incorrect.
This series fixes this for most drivers. D
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.
Push the current calculation into the only direct caller imx. Imx's
hardware requires the framebuffer width to be aligned to 8. The
driver's current approach is actually incorrect,
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Inline code from drm_gem_vram_fill_create_dumb() without
the existing size computation. Align the pitch to a multiple of 8.
Only hibmc and vboxvideo use gem-vram. Hibmc invokes the call to
drm_gem_vram_fill_create_dum
Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer
scanline pitch and allocation size. Implementations of struct
drm_driver.dumb_create can call the new helper for their size
computations.
There is currently quite a bit of code duplication among DRM's
memory managers. Each calculates
The ioctls MODE_CREATE_DUMB and MODE_MAP_DUMB return results into a
memory buffer supplied by user space. On errors, it is possible that
intermediate values are being returned. The exact semantics depends
on the DRM driver's implementation of these ioctls. Although this is
most-likely not a securit
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, June 10, 2025 9:53 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Stefano Stabellini
> ; Andrew Cooper ; Roger
> Pau Monné ; Anthony PERARD
> ; Orzel, Michal ; Julien
> Grall ; Stabellini, Stefano ;
> Sergiy
> Kibrik ; xen-dev
On 12/06/2025 18:36, Alexander Gordeev wrote:
> Commit a1d416bf9faf ("sparc/mm: disable preemption in lazy mmu mode")
> is not necessary anymore, since the lazy MMU mode is entered with a
> spinlock held and sparc does not support Real-Time. Thus, upon entering
> the lazy mode the preemption is alr
1 - 100 of 107 matches
Mail list logo
