* [PATCH 0/5] docs: pt_BR: Complete PGP maintainer guide translation
From: Daniel Pereira @ 2026-03-27 12:55 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, Daniel Pereira
This series provides the complete Brazilian Portuguese (pt_BR) translation
of the Maintainer PGP guide. The translation was performed in stages to
ensure technical consistency and proper review of cryptographic terminology.
In addition to the translation, the first patch includes a minor update
to the maintainer-handbooks index to properly include the KVM x86
subsystem development process notes.
Key highlights of this series:
- Complete translation of the GnuPG setup, smartcard usage, and
Git/Patatt integration.
- Sphinx labels were updated with the '_pt' suffix to ensure unique
namespaces and avoid warnings during the HTML documentation build.
- Adherence to the 80-column line limit for better readability in
plain text.
- Verified with checkpatch.pl (0 errors, 0 warnings).
- Verified with 'make htmldocs' to ensure a clean build.
Daniel Pereira (5):
docs: add maintainer-kvm-x86 to maintainer-handbooks index
docs: pt_BR: start translation of the PGP maintainer guide
docs: pt_BR: continue PGP guide translation
docs: pt_BR: continue PGP guide: Git and maintenance
docs: pt_BR: complete PGP guide translation
Documentation/translations/pt_BR/index.rst | 1 +
.../pt_BR/process/maintainer-handbooks.rst | 1 +
.../pt_BR/process/maintainer-pgp-guide.rst | 913 ++++++++++++++++++
3 files changed, 915 insertions(+)
create mode 100644 Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
--
2.47.3
^ permalink raw reply
* [PATCH 1/5] docs: add maintainer-kvm-x86 to maintainer-handbooks index
From: Daniel Pereira @ 2026-03-27 12:55 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, Daniel Pereira
In-Reply-To: <20260327125538.581064-1-danielmaraboo@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 730 bytes --]
Include the KVM x86 subsystem development process notes to the main documentation tree. This ensures the new maintainer guide is properly indexed and reachable.
---
.../translations/pt_BR/process/maintainer-handbooks.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/translations/pt_BR/process/maintainer-handbooks.rst b/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
index ba36df8ee..bf7a38147 100644
--- a/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
@@ -16,3 +16,4 @@ Conteúdos:
maintainer-netdev
maintainer-soc
maintainer-soc-clean-dts
+ maintainer-kvm-x86
--
2.47.3
^ permalink raw reply related
* [PATCH 2/5] docs: pt_BR: start translation of the PGP maintainer guide
From: Daniel Pereira @ 2026-03-27 12:55 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, Daniel Pereira
In-Reply-To: <20260327125538.581064-1-danielmaraboo@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 11506 bytes --]
Translate the initial sections of the Kernel Maintainer PGP guide
into Brazilian Portuguese.
This first part covers:
- The role of PGP in Linux kernel development.
- The principle of trusting developers instead of infrastructure.
- GnuPG tool requirements and gpg-agent configuration.
- Understanding PGP subkeys and their specific capabilities (S, E, A, C).
- Guidelines for strong passphrases and creating separate signing subkeys.
The translation maintains the 80-column limit and adheres to the
standard cryptographic terminology used in the Portuguese documentation
subsystem.
Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
Documentation/translations/pt_BR/index.rst | 1 +
.../pt_BR/process/maintainer-pgp-guide.rst | 202 ++++++++++++++++++
2 files changed, 203 insertions(+)
create mode 100644 Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst
index 4a094d8b7..3d3d42388 100644
--- a/Documentation/translations/pt_BR/index.rst
+++ b/Documentation/translations/pt_BR/index.rst
@@ -75,3 +75,4 @@ kernel e sobre como ver seu trabalho integrado.
Processo do subsistema SoC <process/maintainer-soc>
Conformidade de DTS para SoC <process/maintainer-soc-clean-dts>
Processo do subsistema KVM x86 <process/maintainer-kvm-x86>
+ Guia de PGP para mantenedores <process/maintainer-pgp-guide>
diff --git a/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
new file mode 100644
index 000000000..e10336a12
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
@@ -0,0 +1,202 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============================================
+Guia de PGP para Mantenedores do Kernel Linux
+=============================================
+
+:Autor: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
+
+Este documento é voltado para desenvolvedores do kernel Linux, e especialmente
+para mantenedores de subsistemas. Ele contém um subconjunto das informações
+discutidas no guia mais geral "`Protegendo a Integridade do Código`_" publicado pela
+Linux Foundation. Leia esse documento para uma discussão mais aprofundada sobre
+alguns dos tópicos mencionados neste guia.
+
+.. _`Protegendo a Integridade do Código`: https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md
+
+O papel do PGP no desenvolvimento do Kernel Linux
+=================================================
+
+O PGP ajuda a garantir a integridade do código que é produzido pela comunidade
+de desenvolvimento do kernel Linux e, em menor grau, a estabelecer canais de
+comunicação confiáveis entre desenvolvedores por meio da troca de e-mails
+assinados com PGP.
+
+O código-fonte do kernel Linux está disponível em dois formatos principais:
+
+- Repositórios de fontes distribuídos (git)
+- Snapshots de lançamentos periódicos (tarballs)
+
+Tanto os repositórios git quanto os tarballs carregam assinaturas PGP dos
+desenvolvedores do kernel que criam os lançamentos oficiais. Essas assinaturas
+oferecem uma garantia criptográfica de que as versões para download
+disponibilizadas via kernel.org ou em quaisquer outros espelhos são idênticas ao
+que esses desenvolvedores têm em suas estações de trabalho. Para esse fim:
+
+- repositórios git fornecem assinaturas PGP em todas as tags
+- tarballs fornecem assinaturas PGP avulsas com todos os downloads
+
+Confiar nos desenvolvedores, não na infraestrutura
+--------------------------------------------------
+
+Desde o comprometimento dos sistemas centrais do kernel.org em 2011, o
+princípio operacional principal do projeto Kernel Archives tem sido assumir
+que qualquer parte da infraestrutura pode ser comprometida a qualquer momento.
+Por este motivo, os administradores tomaram medidas deliberadas para enfatizar
+que a confiança deve ser sempre depositada nos desenvolvedores e nunca na
+infraestrutura de hospedagem de código, independentemente de quão boas sejam
+as práticas de segurança desta última.
+
+O princípio orientador acima é a razão pela qual este guia é necessário.
+Queremos garantir que, ao depositar confiança nos desenvolvedores, não
+estejamos meramente transferindo a culpa por potenciais incidentes de
+segurança futuros para outra pessoa. O objetivo é fornecer um conjunto de
+diretrizes que os desenvolvedores possam usar para criar um ambiente de
+trabalho seguro e proteger as chaves PGP usadas para estabelecer a integridade
+do próprio kernel Linux.
+
+Ferramentas PGP
+===============
+
+Use GnuPG 2.4 ou superior
+-------------------------
+
+Sua distribuição já deve ter o GnuPG instalado por padrão; você só precisa
+verificar se está usando uma versão razoavelmente recente dele. Para verificar,
+execute::
+
+ $ gpg --version | head -n1
+
+Se você tiver a versão 2.4 ou superior, está tudo pronto. Se tiver uma versão
+anterior, você está usando um lançamento do GnuPG que não é mais mantido e
+alguns comandos deste guia podem não funcionar.
+
+Configurar as opções do gpg-agent
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+O agente GnuPG é uma ferramenta auxiliar que iniciará automaticamente sempre
+que você usar o comando ``gpg`` e rodará em segundo plano com o propósito de
+armazenar em cache a frase secreta (passphrase) da chave privada. Existem duas
+opções que você deve conhecer para ajustar quando a frase secreta deve expirar
+do cache:
+
+- ``default-cache-ttl`` (segundos): Se você usar a mesma chave novamente antes
+ que o tempo de vida expire, a contagem regressiva será reiniciada por outro
+ período. O padrão é 600 (10 minutos).
+- ``max-cache-ttl`` (segundos): Independentemente de quão recentemente você
+ tenha usado a chave desde a entrada inicial da frase secreta, se a contagem
+ regressiva do tempo de vida máximo expirar, você terá que digitar a frase
+ secreta novamente. O padrão é 30 minutos.
+
+Se você achar que qualquer um desses padrões é muito curto (ou muito longo),
+você pode editar seu arquivo ``~/.gnupg/gpg-agent.conf`` para definir seus
+próprios valores::
+
+ # definir 30 minutos para ttl regular, e 2 horas para o ttl máximo
+ default-cache-ttl 1800
+ max-cache-ttl 7200
+
+.. note::
+
+ Não é mais necessário iniciar o gpg-agent manualmente no início de sua
+ sessão de shell. Você pode querer verificar seus arquivos rc para remover
+ qualquer coisa que tenha configurado para versões mais antigas do GnuPG,
+ pois elas podem não estar mais agindo da forma correta.
+
+Proteja sua chave PGP
+=====================
+
+Este guia assume que você já possui uma chave PGP que utiliza para fins de
+desenvolvimento do kernel Linux. Se você ainda não possui uma, consulte o
+documento "`Protegendo a Integridade do Código`_" mencionado anteriormente para
+obter orientações sobre como criar uma nova.
+
+Você também deve criar uma nova chave se a sua atual for inferior a 2048
+bits (RSA).
+
+Você também deve criar uma nova chave se a sua atual for inferior a 2048
+bits (RSA).
+
+Entendendo as Subchaves PGP
+---------------------------
+
+Uma chave PGP raramente consiste em um único par de chaves -- geralmente é uma
+coleção de subchaves independentes que podem ser usadas para diferentes
+propósitos com base em suas capacidades, atribuídas no momento de sua criação.
+O PGP define quatro capacidades que uma chave pode ter:
+
+- As chaves **[S]** podem ser usadas para assinatura (*signing*)
+- As chaves **[E]** podem ser usadas para criptografia (*encryption*)
+- As chaves **[A]** podem ser usadas para autenticação (*authentication*)
+- As chaves **[C]** podem ser usadas para certificação de outras chaves
+ (*certifying*)
+
+A chave com a capacidade **[C]** é frequentemente chamada de chave "mestra",
+mas esta terminologia é enganosa porque implica que a chave de Certificação
+pode ser usada no lugar de qualquer outra subchave na mesma cadeia (como uma
+"chave mestra" física pode ser usada para abrir fechaduras feitas para outras
+chaves). Como este não é o caso, este guia irá referir-se a ela como "a chave
+de Certificação" para evitar qualquer ambiguidade.
+
+É fundamental compreender plenamente o seguinte:
+
+1. Todas as subchaves são totalmente independentes umas das outras. Se você
+ perder uma subchave privada, ela não poderá ser restaurada ou recriada a
+ partir de qualquer outra chave privada em sua cadeia.
+2. Com exceção da chave de Certificação, pode haver várias subchaves com
+ capacidades idênticas (ex: você pode ter 2 subchaves de criptografia
+ válidas, 3 subchaves de assinatura válidas, mas apenas uma subchave de
+ certificação válida). Todas as subchaves são totalmente independentes -- uma
+ mensagem criptografada para uma subchave **[E]** não pode ser
+ descriptografada com qualquer outra subchave **[E]** que você também possa
+ ter.
+3. Uma única subchave pode ter múltiplas capacidades (ex: sua chave **[C]**
+ também pode ser sua chave **[S]**).
+
+A chave que carrega a capacidade **[C]** (certificação) é a única chave que
+pode ser usada para indicar relacionamento com outras chaves. Apenas a chave
+**[C]** pode ser usada para:
+
+- adicionar ou revogar outras chaves (subchaves) com capacidades S/E/A
+- adicionar, alterar ou revogar identidades (uids) associadas à chave
+- adicionar ou alterar a data de expiração em si mesma ou em qualquer subchave
+- assinar chaves de outras pessoas para fins de rede de confiança (web of trust)
+
+Por padrão, o GnuPG cria o seguinte ao gerar novas chaves:
+
+- Uma subchave carregando as capacidades de Certificação e Assinatura (**[SC]**)
+- Uma subchave separada com a capacidade de Criptografia (**[E]**)
+
+Se você usou os parâmetros padrão ao gerar sua chave, então é isso que você
+terá. Você pode verificar executando ``gpg --list-secret-keys``, por exemplo::
+
+ sec ed25519 2022-12-20 [SC] [expires: 2024-12-19]
+ 000000000000000000000000AAAABBBBCCCCDDDD
+ uid [ultimate] Alice Dev <adev@kernel.org>
+ ssb cv25519 2022-12-20 [E] [expires: 2024-12-19]
+
+A linha longa abaixo da entrada ``sec`` é o "fingerprint" (impressão digital)
+da sua chave -- sempre que você vir ``[fpr]`` nos exemplos abaixo, é a essa
+string de 40 caracteres que ele se refere.
+
+Certifique-se de que sua frase secreta seja forte
+-------------------------------------------------
+
+O GnuPG usa frases secretas para criptografar suas chaves privadas antes de
+armazená-las no disco. Dessa forma, mesmo que seu diretório ``.gnupg`` seja
+vazado ou roubado em sua totalidade, os invasores não poderão usar suas chaves
+privadas sem primeiro obter a frase secreta para descriptografá-las.
+
+É absolutamente essencial que suas chaves privadas sejam protegidas por uma
+frase secreta forte. Para defini-la ou alterá-la, use::
+
+ $ gpg --change-passphrase [fpr]
+
+Crie uma subchave de assinatura separada
+----------------------------------------
+
+Nosso objetivo é proteger sua chave de Certificação movendo-a para uma mídia
+offline; portanto, se você tiver apenas uma chave **[SC]** combinada, você deve
+criar uma subchave de assinatura separada::
+
+ $ gpg --quick-addkey [fpr] ed25519 sign
\ No newline at end of file
--
2.47.3
^ permalink raw reply related
* [PATCH 3/5] docs: pt_BR: continue PGP guide translation
From: Daniel Pereira @ 2026-03-27 12:55 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, Daniel Pereira
In-Reply-To: <20260327125538.581064-1-danielmaraboo@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 14881 bytes --]
Translate the backup and smartcard-related sections of the PGP
maintainer guide into Brazilian Portuguese.
This update includes:
- Procedures for paperkey and full GnuPG directory backups.
- Guide for identifying keygrips and removing the Certify key from
the local workstation for offline storage.
- Smartcard benefits, hardware options, and initial configuration.
The internal label 'smartcards' was renamed to 'smartcards_pt' to
avoid a global namespace conflict with the original English document
during the Sphinx build.
The file was verified with checkpatch.pl and passes with 0 errors
and 0 warnings.
Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
.../pt_BR/process/maintainer-pgp-guide.rst | 291 +++++++++++++++++-
1 file changed, 290 insertions(+), 1 deletion(-)
diff --git a/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
index e10336a12..280207498 100644
--- a/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
@@ -199,4 +199,293 @@ Nosso objetivo é proteger sua chave de Certificação movendo-a para uma mídia
offline; portanto, se você tiver apenas uma chave **[SC]** combinada, você deve
criar uma subchave de assinatura separada::
- $ gpg --quick-addkey [fpr] ed25519 sign
\ No newline at end of file
+ $ gpg --quick-addkey [fpr] ed25519 sign
+
+Faça backup da sua chave de Certificação para recuperação de desastres
+----------------------------------------------------------------------
+
+Quanto mais assinaturas de outros desenvolvedores você tiver em sua chave PGP,
+mais motivos você terá para criar uma versão de backup que resida em algo que
+não seja mídia digital, por razões de recuperação de desastres.
+
+Uma boa maneira de criar uma cópia impressa da sua chave privada é usando o
+software ``paperkey``, escrito para este propósito específico. Veja
+``man paperkey`` para mais detalhes sobre o formato de saída e seus benefícios
+em relação a outras soluções. O Paperkey já deve estar empacotado para a
+maioria das distribuições.
+
+Execute o seguinte comando para criar um backup impresso da sua chave privada::
+
+ $ gpg --export-secret-key [fpr] | paperkey -o /tmp/key-backup.txt
+
+Imprima esse arquivo, pegue uma caneta e escreva sua frase secreta na margem do
+papel. **Isso é fortemente recomendado** porque a impressão da chave ainda
+está criptografada com essa frase secreta e, se você algum dia alterá-la, você
+não se lembrará de qual era quando criou o backup -- *garantido*.
+
+Coloque a cópia impressa resultante e a frase secreta escrita à mão em um
+envelope e guarde-os em um local seguro e bem protegido, de preferência longe
+de sua casa, como o cofre de um banco.
+
+.. note::
+
+ A chave ainda está criptografada com sua frase secreta, portanto, imprimir
+ mesmo em impressoras modernas "integradas à nuvem" deve continuar sendo uma
+ operação relativamente segura.
+
+Faça backup de todo o seu diretório GnuPG
+-----------------------------------------
+
+.. warning::
+
+ **!!!Não pule esta etapa!!!**
+
+É importante ter um backup prontamente disponível de suas chaves PGP caso
+precise recuperá-las. Isso é diferente da preparação para nível de desastre que
+fizemos com o ``paperkey``. Você também dependerá dessas cópias externas sempre
+que precisar usar sua chave de Certificação -- como ao fazer alterações em sua
+própria chave ou assinar as chaves de outras pessoas após conferências e
+encontros.
+
+Comece obtendo um cartão de mídia externa (de preferência dois!) que você usará
+para fins de backup. Você precisará criar uma partição criptografada neste
+dispositivo usando LUKS -- consulte a documentação de sua distribuição sobre
+como fazer isso.
+
+Para a frase secreta de criptografia, você pode usar a mesma de sua chave PGP.
+
+Assim que o processo de criptografia terminar, insira novamente o dispositivo e
+certifique-se de que ele foi montado corretamente. Copie todo o seu diretório
+``.gnupg`` para o armazenamento criptografado::
+
+ $ cp -a ~/.gnupg /media/disk/foo/gnupg-backup
+
+Você deve agora testar para garantir que tudo ainda funciona::
+
+ $ gpg --homedir=/media/disk/foo/gnupg-backup --list-key [fpr]
+
+Se você não receber nenhum erro, então está tudo pronto. Desmonte o
+dispositivo, identifique-o claramente para não sobrescrevê-lo por acidente e
+guarde-o em um lugar seguro -- mas não muito longe, pois você precisará
+usá-lo de vez em quando para tarefas como editar identidades, adicionar ou
+revogar subchaves, ou assinar as chaves de outras pessoas.
+
+Remova a chave de Certificação de seu diretório pessoal
+-------------------------------------------------------
+
+Os arquivos em nosso diretório pessoal não estão tão bem protegidos quanto
+gostaríamos de pensar. Eles podem ser vazados ou roubados por meio de muitos
+meios diferentes:
+
+- por acidente ao fazer cópias rápidas do diretório pessoal para configurar
+ uma nova estação de trabalho
+- por negligência ou malícia do administrador de sistemas
+- por meio de backups mal protegidos
+- por meio de malware em aplicativos de desktop (navegadores, visualizadores
+ de PDF, etc.)
+- por meio de coação ao cruzar fronteiras internacionais
+
+Proteger sua chave com uma boa frase secreta ajuda muito a reduzir o risco
+de qualquer um dos itens acima, mas as frases secretas podem ser descobertas
+por meio de keyloggers, shoulder-surfing (observação direta) ou qualquer número
+de outros meios. Por este motivo, a configuração recomendada é remover sua
+chave de Certificação de seu diretório pessoal e armazená-la em um
+armazenamento offline.
+
+.. warning::
+
+ Consulte a seção anterior e certifique-se de que você fez o backup do seu
+ diretório GnuPG em sua totalidade. O que estamos prestes a fazer tornará
+ sua chave inútil se você não tiver um backup utilizável!
+
+Primeiro, identifique o "keygrip" da sua chave de Certificação::
+
+ $ gpg --with-keygrip --list-key [fpr]
+
+A saída será algo como isto::
+
+ pub ed25519 2022-12-20 [SC] [expires: 2022-12-19]
+ 000000000000000000000000AAAABBBBCCCCDDDD
+ Keygrip = 1111000000000000000000000000000000000000
+ uid [ultimate] Alice Dev <adev@kernel.org>
+ sub cv25519 2022-12-20 [E] [expires: 2022-12-19]
+ Keygrip = 2222000000000000000000000000000000000000
+ sub ed25519 2022-12-20 [S]
+ Keygrip = 3333000000000000000000000000000000000000
+
+Encontre a entrada keygrip que está abaixo da linha ``pub`` (logo abaixo da
+impressão digital da chave de Certificação). Isso corresponderá diretamente a
+um arquivo em seu diretório ``~/.gnupg``::
+
+ $ cd ~/.gnupg/private-keys-v1.d
+ $ ls
+ 1111000000000000000000000000000000000000.key
+ 2222000000000000000000000000000000000000.key
+ 3333000000000000000000000000000000000000.key
+
+É suficiente remover o arquivo .key que corresponde ao keygrip da chave de
+Certificação::
+
+ $ cd ~/.gnupg/private-keys-v1.d
+ $ rm 1111000000000000000000000000000000000000.key
+
+Agora, se você executar o comando ``--list-secret-keys``, ele mostrará que a
+chave de Certificação está faltando (o símbolo ``#`` indica que ela não está
+disponível)::
+
+ $ gpg --list-secret-keys
+ sec# ed25519 2022-12-20 [SC] [expires: 2024-12-19]
+ 000000000000000000000000AAAABBBBCCCCDDDD
+ uid [ultimate] Alice Dev <adev@kernel.org>
+ ssb cv25519 2022-12-20 [E] [expires: 2024-12-19]
+ ssb ed25519 2022-12-20 [S]
+
+Você também deve remover quaisquer arquivos ``secring.gpg`` no diretório
+``~/.gnupg``, que podem ser remanescentes de versões anteriores do GnuPG.
+
+Se você não tiver o diretório "private-keys-v1.d"
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Se você não tiver um diretório ``~/.gnupg/private-keys-v1.d``, então suas
+chaves secretas ainda estão armazenadas no arquivo legado ``secring.gpg`` usado
+pelo GnuPG v1. Fazer qualquer alteração em sua chave, como mudar a frase
+secreta ou adicionar uma subchave, deve converter automaticamente o formato
+antigo ``secring.gpg`` para usar o ``private-keys-v1.d``.
+
+Assim que concluir isso, certifique-se de excluir o arquivo ``secring.gpg``
+obsoleto, que ainda contém suas chaves privadas.
+
+Mova as subchaves para um dispositivo criptográfico dedicado
+============================================================
+
+Embora a chave de Certificação agora esteja protegida contra vazamentos ou
+roubos, as subchaves ainda estão em seu diretório pessoal. Qualquer pessoa que
+consiga colocar as mãos nelas poderá descriptografar sua comunicação ou forjar
+suas assinaturas (se souberem a frase secreta). Além disso, cada vez que uma
+operação do GnuPG é realizada, as chaves são carregadas na memória do sistema e
+podem ser roubadas por malware suficientemente avançado (pense em Meltdown e
+Spectre).
+
+Uma boa maneira de proteger completamente suas chaves é movê-las para um
+dispositivo de hardware especializado que seja capaz de realizar operações de
+smartcard.
+
+Os benefícios dos smartcards
+----------------------------
+
+Um smartcard contém um chip criptográfico capaz de armazenar chaves privadas e
+realizar operações criptográficas diretamente no próprio cartão. Como o
+conteúdo da chave nunca sai do smartcard, o sistema operacional do computador
+no qual você conecta o dispositivo de hardware não é capaz de recuperar as
+próprias chaves privadas. Isso é muito diferente do dispositivo de
+armazenamento de mídia criptografado que usamos anteriormente para fins de
+backup -- enquanto esse dispositivo estiver conectado e montado, o sistema
+operacional poderá acessar o conteúdo da chave privada.
+
+O uso de mídia criptografada externa não substitui o uso de um dispositivo
+compatível com smartcard.
+
+Dispositivos smartcard disponíveis
+----------------------------------
+
+A menos que todos os seus laptops e estações de trabalho tenham leitores de
+smartcard, o mais fácil é obter um dispositivo USB especializado que implemente
+a funcionalidade de smartcard. Existem várias opções disponíveis:
+
+- `Nitrokey Start (pt)`_: Hardware aberto e Software Livre, baseado no `Gnuk_pt`_ da FSI
+ Japan. Uma das opções mais baratas, mas oferece menos recursos de segurança
+ (como resistência a violações ou alguns ataques de canal lateral).
+- `Nitrokey 3 (pt)`_: Semelhante ao Nitrokey Start, mas mais resistente a violações
+ e oferece mais recursos de segurança e formatos USB. Suporta criptografia ECC
+ (ED25519 e NISTP).
+- `Yubikey 5 (pt)`_: Hardware e software proprietários, mas mais barato que o
+ Nitrokey com um conjunto semelhante de recursos. Suporta criptografia ECC
+ (ED25519 e NISTP).
+
+Sua escolha dependerá do custo, da disponibilidade de envio em sua região
+geográfica e de considerações sobre hardware aberto ou proprietário.
+
+.. note::
+
+ Se você estiver listado em uma entrada `M:` no arquivo MAINTAINERS ou tiver
+ uma conta no kernel.org, você `se qualifica para um Nitrokey Start gratuito`_
+ cortesia da Linux Foundation.
+
+.. _`Nitrokey Start (pt)`: https://www.nitrokey.com/products/nitrokeys
+.. _`Nitrokey 3 (pt)`: https://www.nitrokey.com/products/nitrokeys
+.. _`Yubikey 5 (pt)`: https://www.yubico.com/products/yubikey-5-overview/
+.. _Gnuk_pt: https://www.fsij.org/doc-gnuk/
+.. _`se qualifica para um Nitrokey Start gratuito`: https://www.kernel.org/nitrokey-digital-tokens-for-kernel-developers.html
+
+Configure seu dispositivo smartcard
+-----------------------------------
+
+Seu dispositivo smartcard deve simplesmente funcionar (Just Work - TM) no
+momento em que você o conecta em qualquer estação de trabalho Linux moderna.
+Você pode verificar executando::
+
+ $ gpg --card-status
+
+Se você vir os detalhes completos do smartcard, então está tudo pronto.
+Infelizmente, solucionar todos os possíveis motivos pelos quais as coisas
+podem não estar funcionando para você está muito além do escopo deste guia.
+Se você estiver tendo problemas para fazer a placa funcionar com o GnuPG,
+procure ajuda por meio dos canais usuais de suporte.
+
+Para configurar seu smartcard, você precisará usar o sistema de menus do GnuPG,
+pois não existem opções de linha de comando convenientes::
+
+ $ gpg --card-edit
+ [...omitido...]
+ gpg/card> admin
+ Comandos de administração são permitidos
+ gpg/card> passwd
+
+Você deve configurar o PIN de usuário (1), o PIN de Administrador (3) e o
+Código de Redefinição (4). Por favor, certifique-se de registrar e armazenar
+estes em um local seguro -- especialmente o PIN de Administrador e o Código de
+Redefinição (que permite limpar completamente o smartcard). Você raramente
+precisará usar o PIN de Administrador, de modo que inevitavelmente esquecerá
+o que é se não o registrar.
+
+Voltando ao menu principal do cartão, você também pode definir outros valores
+(como nome, gênero, dados de login, etc.), mas não é necessário e irá,
+adicionalmente, vazar informações sobre o seu smartcard caso você o perca.
+
+.. note::
+
+ Apesar de ter o nome "PIN", nem o PIN de usuário nem o PIN de administrador
+ no cartão precisam ser apenas números.
+
+.. warning::
+
+ Alguns dispositivos podem exigir que você mova as subchaves para o
+ dispositivo antes de poder alterar a frase secreta. Por favor, verifique a
+ documentação fornecida pelo fabricante do dispositivo.
+
+Mova as subchaves para o seu smartcard
+--------------------------------------
+
+Saia do menu do cartão (usando "q") e salve todas as alterações. Em seguida,
+vamos mover suas subchaves para o smartcard. Você precisará tanto da sua
+frase secreta da chave PGP quanto do PIN de administrador do cartão para a
+maioria das operações::
+
+ $ gpg --edit-key [fpr]
+
+ Secret subkeys are available.
+
+ pub ed25519/AAAABBBBCCCCDDDD
+ created: 2022-12-20 expires: 2024-12-19 usage: SC
+ trust: ultimate validity: ultimate
+ ssb cv25519/1111222233334444
+ created: 2022-12-20 expires: never usage: E
+ ssb ed25519/5555666677778888
+ created: 2017-12-07 expires: never usage: S
+ [ultimate] (1). Alice Dev <adev@kernel.org>
+
+ gpg>
+
+Usar ``--edit-key`` nos coloca no modo de menu novamente, e você notará que a
+listagem das chaves é um pouco diferente. De aqui em diante, todos os comandos
+são feitos de dentro deste modo de menu, conforme indicado por ``gpg>``.
\ No newline at end of file
--
2.47.3
^ permalink raw reply related
* [PATCH 4/5] docs: pt_BR: continue PGP guide: Git and maintenance
From: Daniel Pereira @ 2026-03-27 12:55 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, Daniel Pereira
In-Reply-To: <20260327125538.581064-1-danielmaraboo@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 13189 bytes --]
Continue the PGP guide translation covering Git integration,
key maintenance, and the use of the patatt tool.
This update includes:
- Procedures for moving subkeys to hardware (keytocard) and verifying
the transfer.
- PGP maintenance tasks: extending expiration dates and working with
offline backups.
- Git configuration for signing tags and commits automatically.
- Introduction to agent forwarding over SSH and the patatt patch
attestation tool.
Internal Sphinx labels (e.g., 'pgp_with_git', 'verify_identities') were
renamed with a '_pt' suffix to ensure a unique namespace and avoid
build warnings.
The file was verified with checkpatch.pl and passes with 0 errors
and 0 warnings.
Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
.../pt_BR/process/maintainer-pgp-guide.rst | 291 +++++++++++++++++-
1 file changed, 290 insertions(+), 1 deletion(-)
diff --git a/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
index 280207498..e4cc9211b 100644
--- a/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
@@ -488,4 +488,293 @@ maioria das operações::
Usar ``--edit-key`` nos coloca no modo de menu novamente, e você notará que a
listagem das chaves é um pouco diferente. De aqui em diante, todos os comandos
-são feitos de dentro deste modo de menu, conforme indicado por ``gpg>``.
\ No newline at end of file
+são feitos de dentro deste modo de menu, conforme indicado por ``gpg>``.
+
+Primeiro, vamos selecionar a chave que colocaremos no cartão -- você faz isso
+digitando ``key 1`` (é a primeira na listagem, a subchave **[E]**)::
+
+ gpg> key 1
+
+Na saída, você deverá ver agora ``ssb*`` na chave **[E]**. O ``*`` indica qual
+chave está atualmente "selecionada". Ele funciona como uma *alternância*
+(toggle), o que significa que se você digitar ``key 1`` novamente, o ``*``
+desaparecerá e a chave não estará mais selecionada.
+
+Agora, vamos mover essa chave para o smartcard::
+
+ gpg> keytocard
+ Please select where to store the key:
+ (2) Encryption key
+ Your selection? 2
+
+Como é a nossa chave **[E]**, faz sentido colocá-la no slot de Criptografia
+(Encryption). Quando você enviar sua seleção, será solicitada primeiro a frase
+secreta da sua chave PGP e, em seguida, o PIN de administrador. Se o comando
+retornar sem erros, sua chave foi movida.
+
+**Importante**: Agora digite ``key 1`` novamente para desmarcar a primeira chave
+e ``key 2`` para selecionar a chave **[S]**::
+
+ gpg> key 1
+ gpg> key 2
+ gpg> keytocard
+ Please select where to store the key:
+ (1) Signature key
+ (3) Authentication key
+ Your selection? 1
+
+Você pode usar a chave **[S]** tanto para Assinatura quanto para Autenticação,
+mas queremos garantir que ela esteja no slot de Assinatura, então escolha (1).
+Mais uma vez, se o seu comando retornar sem erros, a operação foi
+bem-sucedida::
+
+ gpg> q
+ Save changes? (y/N) y
+
+Salvar as alterações excluirá as chaves que você moveu para o cartão de seu
+diretório pessoal (mas não há problema, pois as temos em nossos backups caso
+precisemos fazer isso novamente para um smartcard de substituição).
+
+Verificando se as chaves foram movidas
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Se você executar ``--list-secret-keys`` agora, verá uma diferença sutil na
+saída::
+
+ $ gpg --list-secret-keys
+ sec# ed25519 2022-12-20 [SC] [expires: 2024-12-19]
+ 000000000000000000000000AAAABBBBCCCCDDDD
+ uid [ultimate] Alice Dev <adev@kernel.org>
+ ssb> cv25519 2022-12-20 [E] [expires: 2024-12-19]
+ ssb> ed25519 2022-12-20 [S]
+
+O ``>`` na saída ``ssb>`` indica que a subchave está disponível apenas no
+smartcard. Se você voltar ao diretório de chaves secretas e observar o
+conteúdo, notará que os arquivos ``.key`` foram substituídos por stubs::
+
+ $ cd ~/.gnupg/private-keys-v1.d
+ $ strings *.key | grep 'private-key'
+
+A saída deve conter ``shadowed-private-key`` para indicar que esses arquivos
+são apenas stubs e o conteúdo real está no smartcard.
+
+Verificando se o smartcard está funcionando
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Para verificar se o smartcard está funcionando conforme o esperado, você pode
+criar uma assinatura::
+
+ $ echo "Hello world" | gpg --clearsign > /tmp/test.asc
+ $ gpg --verify /tmp/test.asc
+
+Isso deve solicitar o PIN do seu smartcard no primeiro comando e, em seguida,
+mostrar "Good signature" após você executar ``gpg --verify``.
+
+Parabéns, você conseguiu tornar extremamente difícil o roubo da sua identidade
+digital de desenvolvedor!
+
+Outras operações comuns do GnuPG
+--------------------------------
+
+Aqui está uma referência rápida para algumas operações comuns que você
+precisará realizar com sua chave PGP.
+
+Montando seu armazenamento offline seguro
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Você precisará da sua chave de Certificação para qualquer uma das operações
+abaixo, portanto, primeiro precisará montar seu armazenamento offline de backup
+e dizer ao GnuPG para usá-lo::
+
+ $ export GNUPGHOME=/media/disk/foo/gnupg-backup
+ $ gpg --list-secret-keys
+
+Certifique-se de ver ``sec`` e não ``sec#`` na saída (o símbolo ``#``
+significa que a chave não está disponível e você ainda está usando o local
+padrão do seu diretório pessoal).
+
+Estendendo a data de expiração da chave
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A chave de Certificação tem uma data de expiração padrão de 2 anos a partir da
+data de criação. Isso é feito tanto por razões de segurança quanto para fazer
+com que chaves obsoletas eventualmente desapareçam dos servidores de chaves
+(keyservers).
+
+Para estender a expiração da sua chave em um ano a partir da data atual, basta
+executar::
+
+ $ gpg --quick-set-expire [fpr] 1y
+
+Você também pode usar uma data específica se for mais fácil de lembrar (por
+exemplo, seu aniversário ou 1º de janeiro)::
+
+ $ gpg --quick-set-expire [fpr] 2038-07-01
+
+Lembre-se de enviar a chave atualizada de volta para os servidores de chaves::
+
+ $ gpg --send-key [fpr]
+
+Atualizando seu diretório de trabalho após alterações
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Depois de fazer qualquer alteração em sua chave usando o armazenamento offline,
+você desejará importar essas alterações de volta para o seu diretório de
+trabalho normal::
+
+ $ gpg --export | gpg --homedir ~/.gnupg --import
+ $ unset GNUPGHOME
+
+Usando gpg-agent sobre SSH
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Você pode encaminhar seu gpg-agent sobre SSH se precisar assinar tags ou
+commits em um sistema remoto. Por favor, consulte as instruções fornecidas
+na wiki do GnuPG:
+
+- `Encaminhamento de Agent sobre SSH (pt)`_
+
+Funciona de forma mais fluida se você puder modificar as configurações do
+servidor sshd na extremidade remota.
+
+.. _`Encaminhamento de Agent sobre SSH (pt)`: https://wiki.gnupg.org/AgentForwarding
+
+Usando PGP com Git
+==================
+
+Uma das principais características do Git é sua natureza descentralizada --
+uma vez que um repositório é clonado em seu sistema, você tem o histórico
+completo do projeto, incluindo todas as suas tags, commits e branches. No
+entanto, com centenas de repositórios clonados por aí, como alguém verifica
+se sua cópia do linux.git não foi adulterada por um terceiro mal-intencionado?
+
+Ou o que acontece se um código malicioso for descoberto no kernel e a linha
+"Author" no commit disser que foi feito por você, enquanto você tem certeza
+de que `não teve relação com isso (pt)`_?
+
+Para resolver ambas as questões, o Git introduziu a integração com PGP. Tags
+assinadas provam a integridade do repositório, garantindo que seu conteúdo é
+exatamente o mesmo que estava na estação de trabalho do desenvolvedor que
+criou a tag, enquanto commits assinados tornam quase impossível para alguém
+se passar por você sem ter acesso às suas chaves PGP.
+
+.. _`não teve relação com isso (pt)`: https://github.com/jayphelps/git-blame-someone-else
+
+Configure o git para usar sua chave PGP
+---------------------------------------
+
+Se você tiver apenas uma chave secreta em seu chaveiro, não precisará fazer
+nada extra, pois ela se torna sua chave padrão. No entanto, se você tiver
+várias chaves secretas, poderá informar ao git qual chave deve ser usada
+(``[fpr]`` é a impressão digital da sua chave)::
+
+ $ git config --global user.signingKey [fpr]
+
+Como trabalhar com tags assinadas
+---------------------------------
+
+Para criar uma tag assinada, passe a opção ``-s`` para o comando tag::
+
+ $ git tag -s [tagname]
+
+Nossa recomendação é sempre assinar as tags do git, pois isso permite que outros
+desenvolvedores garantam que o repositório git do qual estão baixando não foi
+alterado de forma maliciosa.
+
+Como verificar tags assinadas
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Para verificar uma tag assinada, use o comando ``verify-tag``::
+
+ $ git verify-tag [tagname]
+
+Se você estiver baixando (pulling) uma tag de outro fork do repositório do
+projeto, o git deve verificar automaticamente a assinatura na ponta (tip) que
+você está baixando e mostrar os resultados durante a operação de merge::
+
+ $ git pull [url] tags/sometag
+
+A mensagem de merge conterá algo como isto::
+
+ Merge tag 'sometag' of [url]
+
+ [Tag message]
+
+ # gpg: Signature made [...]
+ # gpg: Good signature from [...]
+
+Se você estiver verificando a tag git de outra pessoa, primeiro precisará
+importar a chave PGP dela. Por favor, consulte a seção
+":ref:`verificar_identidades_pt`" abaixo.
+
+Configure o git para sempre assinar tags anotadas
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+É provável que, se você estiver criando uma tag anotada, você desejará
+assiná-la. Para forçar o git a sempre assinar tags anotadas, você pode definir
+uma opção de configuração global::
+
+ $ git config --global tag.forceSignAnnotated true
+
+Como trabalhar com commits assinados
+------------------------------------
+
+Também é possível criar commits assinados, mas eles têm utilidade limitada no
+desenvolvimento do kernel Linux. O fluxo de trabalho de contribuição do kernel
+depende do envio de patches, e a conversão de commits em patches não preserva
+as assinaturas de commit do git. Além disso, ao fazer o rebase do seu próprio
+repositório em um upstream mais recente, as assinaturas PGP de commit acabarão
+sendo descartadas. Por esse motivo, a maioria dos desenvolvedores do kernel não
+se preocupa em assinar seus commits e ignorará commits assinados em quaisquer
+repositórios externos nos quais dependam para o seu trabalho.
+
+Dito isso, se você tem sua árvore git de trabalho disponível publicamente em
+algum serviço de hospedagem git (kernel.org, infradead.org, ozlabs.org ou
+outros), a recomendação é que você assine todos os seus commits do git, mesmo
+que os desenvolvedores upstream não se beneficiem diretamente dessa prática.
+
+Recomendamos isso pelos seguintes motivos:
+
+1. Caso haja necessidade de realizar uma análise forense de código ou rastrear a
+ proveniência do código, mesmo as árvores mantidas externamente contendo
+ assinaturas PGP de commit serão valiosas para tais fins.
+2. Se você precisar clonar novamente seu repositório local (por exemplo, após
+ reinstalar seu sistema), isso permite verificar a integridade do repositório
+ antes de retomar seu trabalho.
+3. Se alguém precisar fazer o cherry-pick dos seus commits, isso permite que
+ verifiquem rapidamente a integridade deles antes de aplicá-los.
+
+Criando commits assinados
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Para criar um commit assinado, passe a flag ``-S`` para o comando
+``git commit`` (é um ``-S`` maiúsculo devido à colisão com outra flag)::
+
+ $ git commit -S
+
+Configure o git para sempre assinar commits
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Você pode informar ao git para sempre assinar os commits::
+
+ git config --global commit.gpgSign true
+
+.. note::
+
+ Certifique-se de configurar o ``gpg-agent`` antes de ativar esta opção.
+
+.. _verificar_identidades_pt:
+
+Como trabalhar com patches assinados
+------------------------------------
+
+É possível usar sua chave PGP para assinar patches enviados para as listas de
+discussão de desenvolvedores do kernel. Como os mecanismos existentes de
+assinatura de e-mail (PGP-Mime ou PGP-inline) tendem a causar problemas com as
+tarefas regulares de revisão de código, você deve usar a ferramenta que o
+kernel.org criou para este fim, que coloca assinaturas de atestação
+criptográfica nos cabeçalhos das mensagens (estilo DKIM):
+
+- `Atestação de Patch Patatt (pt)`_
+
+.. _`Atestação de Patch Patatt (pt)`: https://pypi.org/project/patatt/
\ No newline at end of file
--
2.47.3
^ permalink raw reply related
* [PATCH 5/5] docs: pt_BR: complete PGP guide translation
From: Daniel Pereira @ 2026-03-27 12:55 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, Daniel Pereira
In-Reply-To: <20260327125538.581064-1-danielmaraboo@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 7925 bytes --]
Finish the translation of the PGP maintainer guide into Brazilian
Portuguese, covering advanced tools and identity verification.
This final part adds:
- Detailed configuration for the patatt patch attestation tool.
- Integration of gpg-agent with SSH for remote signing.
- Procedures for verifying kernel developer identities.
- Technical overview of WOT (Web of Trust) vs. TOFU models.
- Automated key discovery via WKD and DANE (DNSSEC/TLS).
- Usage of the kernel.org PGP keyring repository.
All internal cross-references and labels were updated with the '_pt'
suffix to maintain a clean namespace during the Sphinx build.
The document passes checkpatch.pl with 0 errors/warnings and builds
perfectly with 'make htmldocs'.
Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
.../pt_BR/process/maintainer-pgp-guide.rst | 135 +++++++++++++++++-
1 file changed, 134 insertions(+), 1 deletion(-)
diff --git a/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
index e4cc9211b..78cc393e0 100644
--- a/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
@@ -777,4 +777,137 @@ criptográfica nos cabeçalhos das mensagens (estilo DKIM):
- `Atestação de Patch Patatt (pt)`_
-.. _`Atestação de Patch Patatt (pt)`: https://pypi.org/project/patatt/
\ No newline at end of file
+.. _`Atestação de Patch Patatt (pt)`: https://pypi.org/project/patatt/
+
+Instalando e configurando o patatt
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. note::
+
+ Se você usa o B4 para enviar seus patches, o patatt já está instalado
+ e integrado ao seu fluxo de trabalho.
+
+O patatt já está empacotado para muitas distribuições, portanto, verifique-as
+primeiro. Você também pode instalá-lo a partir do pypi usando
+"``pip install patatt``".
+
+Se você já tem sua chave PGP configurada com o git (via o parâmetro de
+configuração ``user.signingKey``), o patatt não requer nenhuma configuração
+adicional. Você pode começar a assinar seus patches instalando o hook do
+git-send-email no repositório que desejar::
+
+ patatt install-hook
+
+Agora, quaisquer patches que você enviar com ``git send-email`` serão
+automaticamente assinados com sua assinatura criptográfica.
+
+Verificando assinaturas do patatt
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Se você estiver usando o ``b4`` para recuperar e aplicar patches, ele tentará
+verificar automaticamente todas as assinaturas DKIM e patatt que encontrar,
+por exemplo::
+
+ $ b4 am 20220720205013.890942-1-broonie@kernel.org
+ [...]
+ Checking attestation on all messages, may take a moment...
+ ---
+ ✓ [PATCH v1 1/3] kselftest/arm64: Correct buffer allocation for SVE Z registers
+ ✓ [PATCH v1 2/3] arm64/sve: Document our actual ABI for clearing registers on syscall
+ ✓ [PATCH v1 3/3] kselftest/arm64: Enforce actual ABI for SVE syscalls
+ ---
+ ✓ Signed: openpgp/broonie@kernel.org
+ ✓ Signed: DKIM/kernel.org
+
+.. note::
+
+ O patatt e o b4 ainda estão em desenvolvimento ativo e você deve consultar
+ a documentação mais recente desses projetos para quaisquer recursos novos
+ ou atualizados.
+
+Como verificar identidades de desenvolvedores do kernel
+=======================================================
+
+Assinar tags e commits é simples, mas como verificar se a chave usada para
+assinar algo pertence ao desenvolvedor real do kernel e não a um impostor
+mal-intencionado?
+
+Configurar a recuperação automática de chaves usando WKD e DANE
+---------------------------------------------------------------
+
+Se você ainda não possui uma vasta coleção de chaves públicas de outros
+desenvolvedores, pode dar um pontapé inicial em seu chaveiro confiando na
+autodescoberta e recuperação automática de chaves. O GnuPG pode se apoiar em
+outras tecnologias de confiança delegada, especificamente DNSSEC e TLS, para
+ajudá-lo se a perspectiva de começar sua própria teia de confiança (Web of Trust)
+do zero for muito desanimadora.
+
+Adicione o seguinte ao seu ``~/.gnupg/gpg.conf``::
+
+ auto-key-locate wkd,dane,local
+ auto-key-retrieve
+
+O DANE (DNS-Based Authentication of Named Entities) é um método para publicar
+chaves públicas no DNS e protegê-las usando zonas assinadas por DNSSEC. O WKD
+(Web Key Directory) é o método alternativo que usa consultas https para o mesmo
+propósito. Ao usar DANE ou WKD para buscar chaves públicas, o GnuPG validará o
+DNSSEC ou os certificados TLS, respectivamente, antes de adicionar as chaves
+públicas recuperadas automaticamente ao seu chaveiro local.
+
+O Kernel.org publica o WKD para todos os desenvolvedores que possuem contas
+kernel.org. Uma vez que você tenha as alterações acima em seu ``gpg.conf``, você
+poderá recuperar automaticamente as chaves de Linus Torvalds e Greg
+Kroah-Hartman (caso ainda não as tenha)::
+
+ $ gpg --locate-keys torvalds@kernel.org gregkh@kernel.org
+
+Se você tem uma conta kernel.org, deve `adicionar o UID do kernel.org à sua chave (pt)`_
+para tornar o WKD mais útil para outros desenvolvedores do kernel.
+
+.. _`adicionar o UID do kernel.org à sua chave (pt)`: https://korg.docs.kernel.org/mail.html#adding-a-kernel-org-uid-to-your-pgp-key
+
+Web of Trust (WOT) vs. Trust on First Use (TOFU)
+------------------------------------------------
+
+O PGP incorpora um mecanismo de delegação de confiança conhecido como "Teia de
+Confiança" (Web of Trust - WOT). Em sua essência, trata-se de uma tentativa de
+substituir a necessidade de Autoridades de Certificação centralizadas do mundo
+HTTPS/TLS. Em vez de vários fabricantes de software ditarem quem deve ser sua
+entidade certificadora de confiança, o PGP deixa essa responsabilidade para cada
+usuário.
+
+Infelizmente, pouquíssimas pessoas entendem como a Teia de Confiança funciona.
+Embora ainda seja uma parte importante da especificação OpenPGP, as versões
+recentes do GnuPG (2.2 e superiores) implementaram um mecanismo alternativo
+chamado "Confiança no Primeiro Uso" (Trust on First Use - TOFU). Você pode
+pensar no TOFU como "a abordagem de confiança estilo SSH". Com o SSH, na primeira
+vez que você se conecta a um sistema remoto, o fingerprint da chave dele é
+gravado e lembrado. Se a chave mudar no futuro, o cliente SSH o alertará e se
+recusará a conectar, forçando-o a tomar uma decisão sobre confiar ou não na
+chave alterada. Da mesma forma, na primeira vez que você importa a chave PGP de
+alguém, assume-se que ela é válida. Se em algum momento no futuro o GnuPG se
+deparar com outra chave com a mesma identidade, tanto a chave importada
+anteriormente quanto a nova chave serão marcadas para verificação, e você
+precisará descobrir manualmente qual delas manter.
+
+Recomendamos que você use o modelo de confiança combinado TOFU+PGP (que é o novo
+padrão no GnuPG v2). Para configurá-lo, adicione (ou modifique) a configuração
+``trust-model`` em ``~/.gnupg/gpg.conf``::
+
+ trust-model tofu+pgp
+
+Usando o repositório Web of Trust do kernel.org
+-----------------------------------------------
+
+O kernel.org mantém um repositório git com as chaves públicas dos
+desenvolvedores como um substituto para as redes de servidores de chaves
+(keyservers) que ficaram em grande parte inativas nos últimos anos. A
+documentação completa sobre como configurar esse repositório como sua fonte de
+chaves públicas pode ser encontrada aqui:
+
+- `Chaveiro PGP de desenvolvedores do Kernel (pt)`_
+
+Se você é um desenvolvedor do kernel, considere enviar sua chave para inclusão
+nesse chaveiro.
+
+.. _`Chaveiro PGP de desenvolvedores do Kernel (pt)`: https://korg.docs.kernel.org/pgpkeys.html
\ No newline at end of file
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-03-27 12:56 UTC (permalink / raw)
To: Maxime Ripard, Ville Syrjälä
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acVzwRyk_J24GrJ4@intel.com>
On Thursday, 26 March 2026 18:58:25 Central European Standard Time Ville Syrjälä wrote:
> On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > +enum drm_connector_color_format {
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > > > > > + * semantics.
> > > > > > > > > > + *
> > > > > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > > > > > + * YCbCr 4:2:0.
> > > > > > > > > > + *
> > > > > > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > > > > > + * as has already been the case before the introduction of the "color
> > > > > > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > > > > > + * how HDMI does it).
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > + * not subsampled)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > >
> > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > should be for each format.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > by other properties.
> > > > > > > >
> > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > knowledge, and hopefully none ever will.
> > > > > > >
> > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > >
> > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > RGB can either be full or limited range depending on the
> > > > > > > "Broadcast RGB" property and other related factors.
> > > > > >
> > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > field of its own?
> > > > >
> > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > I think the assumption is limited range everywhere.
> > > > >
> > > > > But I'm not really concerned about documenting struct members.
> > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > will want to know what the new property actually does so the
> > > > > uapi needs to be documented properly. And down the line some
> > > > > new driver might also implement the wrong behaviour if there
> > > > > is no clear specification.
> > > >
> > > > Ack
> > > >
> > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > - YCbCr limited range
> > > > > - RGB full range if "Broadcast RGB" property is not present
> > > >
> > > > Isn't it much more complicated than that for HDMI though? My
> > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > anything else full range?
> > >
> > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > those would always go hand in hand now.
> >
> > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > think?) but it looks like only vc4 registers the Broadcast RGB property
> > and uses the HDMI state helpers.
> >
> > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > drm_default_rgb_quant_range() which seems suspicious?
>
> If they want just manual full vs. limited then they should
> limit the property to not expose the "auto" option at all.
>
> amdgpu also ties this in with the "colorspace" property, which
> originally in i915 only controlled the infoframes/etc. But on
> amdgpu it now controls various aspects of output color
> transformation. The end result is that the property is a complete
> mess with most of the values making no sense. And for whatever
> reason everyone involved refused to remove/deprecate the
> nonsensical values :/
>
> Looks like this series should make sure the documentation for
> the "colorspace" property is in sync with the new property
> as well. Currently now it's giving conflicting information.
>
I take it the problematic information is in
* DOC: standard connector properties
*
* Colorspace:
and probably specifically BT2020_YCC's (and BT2020_RGB's?) insistence
that they "produce RGB content".
I think we probably just have to change the statement "The variants
BT2020_RGB and BT2020_YCC are equivalent and the driver chooses between
RGB and YCbCr on its own."
The "on its own" here would get turned into "based on the color format
property".
Speaking of i915, that patch is one of the very few (5) patches in
this series still lacking a review (hint hint nudge nudge). I'd like
to get some more feedback on the remaining patches before I send out
another revision, so that it's hopefully not just docs changes (I
know better than to think those patches must be perfect and won't
need revision.)
If `drm/bridge: Act on the DRM color format property` and
`drm/atomic-helper: Add HDMI bridge output bus formats helper` get a
reviewed-by/acked-by and it's still crickets on the amdgpu and i915
front, then I will just drop the amdgpu/i915 implementations so that
they don't block this from landing.
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* Re: [PATCH v9 2/9] lib: vsprintf: export simple_strntoull() in a safe prototype
From: David Laight @ 2026-03-27 13:28 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Petr Mladek, rodrigo.alencar, linux-kernel, linux-iio, devicetree,
linux-doc, Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Steven Rostedt, Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <acZitENbWQF7cmDA@ashevche-desk.local>
On Fri, 27 Mar 2026 12:57:56 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Fri, Mar 27, 2026 at 10:44:40AM +0000, David Laight wrote:
,,,
> > > but also wants to have the fraction part be limited in some cases to s32
> > > or so:
> > >
> > > struct float
> > > {
> > > s64 integer;
> > > s32 fraction; // precision may be lost if input is longer
> > > }
> >
> > Are those 'fraction' counts of (say) 10^-6 (like times in seconds+usecs)
> > or true binary values where the value could be treated as a u64 (or u128)
> > for addition and subtraction.
>
> It depends. IIO has scale on top of that, so the fraction part can be 10⁻³,
> 10⁻⁶, 10⁻⁹. I don't remember by heart if the ABI requires all digits to be
> placed, I think we don't require that.
Seems like you want this function (untested):
u64 strtofrac(const char *buf, const char **end, unsigned int len)
{
u64 val = 0;
unsigned int digit;
while (len--) {
digit = *buf - '0';
if (digit <= 9) {
buf++;
val += digit;
}
val *= 10;
}
while (*buf - '0' <= 9u)
buf++;
*end = buf;
return val;
}
David
^ permalink raw reply
* Re: [PATCH v2 1/4] clk: move core flags into a new enum for kernel docs
From: Brian Masney @ 2026-03-27 13:30 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Maxime Ripard, Jonathan Corbet,
Shuah Khan
Cc: linux-clk, linux-kernel, linux-doc
In-Reply-To: <20260325-clk-docs-v2-1-bcf660e1ceb5@redhat.com>
Hi Stephen,
On Wed, Mar 25, 2026 at 07:52:10PM -0400, Brian Masney wrote:
> Let's move all of the existing clk flags into a new enum so that all of
> the flags can be easily referenced in the kernel documentation. Note
> that I went with name clk_core_flags for the enum since the name
> clk_flags is already in use in clk.c for the debugfs interface.
>
> Note: The comment about "Please update clk_flags..." is included as a
> separate comment so it doesn't show up in the generated documents.
>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> ---
> include/linux/clk-provider.h | 55 +++++++++++++++++++++++++++-----------------
> 1 file changed, 34 insertions(+), 21 deletions(-)
>
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 630705a47129453c241f1b1755f2c2f2a7ed8f77..cb167c17c4f79cf438a26bb113b4968d0f223468 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -9,29 +9,42 @@
> #include <linux/of.h>
> #include <linux/of_clk.h>
>
> -/*
> - * flags used across common struct clk. these flags should only affect the
> - * top-level framework. custom flags for dealing with hardware specifics
> - * belong in struct clk_foo
> +/* Please update clk_flags[] in drivers/clk/clk.c when making changes here! */
> +/**
> + * enum clk_core_flags - framework-level clock flags
> *
> - * Please update clk_flags[] in drivers/clk/clk.c when making changes here!
> + * These flags should only affect the top-level framework. Custom flags for
> + * dealing with hardware specifics belong in struct clk_foo.
> + *
> + * @CLK_SET_RATE_GATE: must be gated across rate change
> + * @CLK_SET_PARENT_GATE: must be gated across re-parent
> + * @CLK_SET_RATE_PARENT: propagate rate change up one level
> + * @CLK_IGNORE_UNUSED: do not gate even if unused
> + * @CLK_GET_RATE_NOCACHE: do not use the cached clk rate
> + * @CLK_SET_RATE_NO_REPARENT: don't re-parent on rate change
> + * @CLK_GET_ACCURACY_NOCACHE: do not use the cached clk accuracy
> + * @CLK_RECALC_NEW_RATES: recalc rates after notifications
> + * @CLK_SET_RATE_UNGATE: clock needs to run to set rate
> + * @CLK_IS_CRITICAL: do not gate, ever
> + * @CLK_OPS_PARENT_ENABLE: parents need enable during gate/ungate, set rate and re-parent
> + * @CLK_DUTY_CYCLE_PARENT: duty cycle call may be forwarded to the parent clock
> */
> -#define CLK_SET_RATE_GATE BIT(0) /* must be gated across rate change */
> -#define CLK_SET_PARENT_GATE BIT(1) /* must be gated across re-parent */
> -#define CLK_SET_RATE_PARENT BIT(2) /* propagate rate change up one level */
> -#define CLK_IGNORE_UNUSED BIT(3) /* do not gate even if unused */
> - /* unused */
> - /* unused */
> -#define CLK_GET_RATE_NOCACHE BIT(6) /* do not use the cached clk rate */
> -#define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate change */
> -#define CLK_GET_ACCURACY_NOCACHE BIT(8) /* do not use the cached clk accuracy */
> -#define CLK_RECALC_NEW_RATES BIT(9) /* recalc rates after notifications */
> -#define CLK_SET_RATE_UNGATE BIT(10) /* clock needs to run to set rate */
> -#define CLK_IS_CRITICAL BIT(11) /* do not gate, ever */
> -/* parents need enable during gate/ungate, set rate and re-parent */
> -#define CLK_OPS_PARENT_ENABLE BIT(12)
> -/* duty cycle call may be forwarded to the parent clock */
> -#define CLK_DUTY_CYCLE_PARENT BIT(13)
> +enum clk_core_flags {
> + CLK_SET_RATE_GATE = BIT(0),
> + CLK_SET_PARENT_GATE = BIT(1),
> + CLK_SET_RATE_PARENT = BIT(2),
> + CLK_IGNORE_UNUSED = BIT(3),
> + /* unused */
> + /* unused */
> + CLK_GET_RATE_NOCACHE = BIT(6),
> + CLK_SET_RATE_NO_REPARENT = BIT(7),
> + CLK_GET_ACCURACY_NOCACHE = BIT(8),
> + CLK_RECALC_NEW_RATES = BIT(9),
> + CLK_SET_RATE_UNGATE = BIT(10),
> + CLK_IS_CRITICAL = BIT(11),
> + CLK_OPS_PARENT_ENABLE = BIT(12),
> + CLK_DUTY_CYCLE_PARENT = BIT(13),
> +};
I just checked Sashiko [1] for this series and it has this comment:
Could converting these unsigned long bitmasks to an enum create a silent
type-safety trap if flags ever reach BIT(31)?
The flags fields in the clock framework are explicitly designed to be 64-bit
on 64-bit architectures (unsigned long). The BIT() macro evaluates to an
unsigned long. When defined as macros, operations like clearing flags
produce a 64-bit inverted mask, perfectly preserving the upper 32 bits.
By moving these flags into an enum, their types are implicitly downgraded to
int, since the current maximum flag BIT(13) fits in a 32-bit signed integer.
If the flags ever grow to include BIT(31), the enumerator value will overflow
a signed 32-bit int, causing the compiler to type it as an unsigned int.
Applying a bitwise NOT to this unsigned int will produce an unsigned int.
When this is bitwise ANDed with the 64-bit unsigned long flags variable,
the unsigned mask will zero-extend to 64 bits, silently clearing all upper
32 bits (bits 32-63) of the flags field.
Would it be safer to keep them as #define macros and use a DOC: block
to properly document the flags using kernel-doc without breaking type safety?
It's up to you how we should proceed with this.
[1] https://sashiko.dev/#/patchset/20260325-clk-docs-v2-0-bcf660e1ceb5%40redhat.com
Brian
^ permalink raw reply
* Re: [PATCH v2] bootconfig: Apply early options from embedded config
From: Masami Hiramatsu @ 2026-03-27 13:37 UTC (permalink / raw)
To: Breno Leitao
Cc: Jonathan Corbet, Shuah Khan, linux-kernel, linux-trace-kernel,
linux-doc, oss, paulmck, rostedt, kernel-team
In-Reply-To: <acZPZ4XKy4QynznK@gmail.com>
On Fri, 27 Mar 2026 03:06:41 -0700
Breno Leitao <leitao@debian.org> wrote:
> Hi Masami,
>
> On Wed, Mar 25, 2026 at 11:22:04PM +0900, Masami Hiramatsu wrote:
> > On Wed, 25 Mar 2026 03:05:38 -0700
> > Breno Leitao <leitao@debian.org> wrote:
>
> > > +/*
> > > + * bootconfig_apply_early_params - dispatch kernel.* keys from the embedded
> > > + * bootconfig as early_param() calls.
> > > + *
> > > + * early_param() handlers must run before most of the kernel initialises
> > > + * (e.g. before the GIC driver reads irqchip.gicv3_pseudo_nmi). A bootconfig
> > > + * attached to the initrd arrives too late for this because the initrd is not
> > > + * mapped yet when early params are processed. The embedded bootconfig lives
> > > + * in the kernel image itself (.init.data), so it is always reachable.
> > > + *
> > > + * This function is called from setup_boot_config() which runs in
> > > + * start_kernel() before parse_early_param(), making the timing correct.
> > > + */
> > > +static void __init bootconfig_apply_early_params(void)
> >
> > [sashiko comment]
> > | Does this run early enough for architectural parameters?
> > | While setup_boot_config() runs before parse_early_param() in start_kernel(),
> > | it runs after setup_arch(). setup_boot_config() relies on xbc_init() which
> > | uses the memblock allocator, requiring setup_arch() to have already
> > | initialized it.
> > | However, the kernel expects many early parameters (like mem=, earlycon,
> > | noapic, and iommu) to be parsed during setup_arch() via the architecture's
> > | call to parse_early_param(). Since setup_arch() completes before
> > | setup_boot_config() runs, will these architectural early parameters be
> > | silently ignored because the decisions they influence were already
> > | finalized?
> >
> > This is the major reason that I did not support early parameter
> > in bootconfig. Some archs initialize kernel_cmdline in setup_arch()
> > and setup early parameters in it.
>
> Would it be feasible to document which parameters are architecture-specific
> and must be processed during setup_arch()?
Yeah, at least we can mark what is not available in bootconfig.
Or, maybe we can export this function to setup_arch() for each
architecture.
Anyway, some cmdline options are not possible to be passed via
bootconfig. IIRC, for example, the initrd image address is
passed via cmdline (via devicetree) on arm64 from bootloader.
>
> We could potentially introduce a third parameter category alongside the
> existing early_param() and __setup():
>
> * early_param()
> * __setup()
> * early_arch_param() (New)
>
> This would allow bootconfig to support __setup() and early_param() while
> explicitly excluding early_arch_param() from bootconfig processing.
Yeah, that maybe possible.
>
> This would move break down the early parameters in those that can be
> easily handled.
>
> > To fix this, we need to change setup_arch() for each architecture so
> > that it calls this bootconfig_apply_early_params().
>
> Could we instead integrate this into parse_early_param() itself? That
> approach would avoid the need to modify each architecture individually.
Ah, indeed.
Thanks!
>
> Thanks for looking at it,
> --breno
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/5] docs: pt_BR: start translation of the PGP maintainer guide
From: Mauro Carvalho Chehab @ 2026-03-27 14:04 UTC (permalink / raw)
To: Daniel Pereira; +Cc: Jonathan Corbet, linux-doc
In-Reply-To: <20260327125538.581064-3-danielmaraboo@gmail.com>
Hi Daniel,
On Fri, 27 Mar 2026 09:55:33 -0300
Daniel Pereira <danielmaraboo@gmail.com> wrote:
> Translate the initial sections of the Kernel Maintainer PGP guide
> into Brazilian Portuguese.
While I don't intend to review those translations, I ended reading
this one for curiosity and found one issue ;-)
>
> This first part covers:
> - The role of PGP in Linux kernel development.
> - The principle of trusting developers instead of infrastructure.
> - GnuPG tool requirements and gpg-agent configuration.
> - Understanding PGP subkeys and their specific capabilities (S, E, A, C).
> - Guidelines for strong passphrases and creating separate signing subkeys.
>
> The translation maintains the 80-column limit and adheres to the
> standard cryptographic terminology used in the Portuguese documentation
> subsystem.
>
> Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
> ---
> Documentation/translations/pt_BR/index.rst | 1 +
> .../pt_BR/process/maintainer-pgp-guide.rst | 202 ++++++++++++++++++
> 2 files changed, 203 insertions(+)
> create mode 100644 Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
>
> diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst
> index 4a094d8b7..3d3d42388 100644
> --- a/Documentation/translations/pt_BR/index.rst
> +++ b/Documentation/translations/pt_BR/index.rst
> @@ -75,3 +75,4 @@ kernel e sobre como ver seu trabalho integrado.
> Processo do subsistema SoC <process/maintainer-soc>
> Conformidade de DTS para SoC <process/maintainer-soc-clean-dts>
> Processo do subsistema KVM x86 <process/maintainer-kvm-x86>
> + Guia de PGP para mantenedores <process/maintainer-pgp-guide>
> diff --git a/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
> new file mode 100644
> index 000000000..e10336a12
> --- /dev/null
> +++ b/Documentation/translations/pt_BR/process/maintainer-pgp-guide.rst
> @@ -0,0 +1,202 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +=============================================
> +Guia de PGP para Mantenedores do Kernel Linux
> +=============================================
> +
> +:Autor: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
> +
> +Este documento é voltado para desenvolvedores do kernel Linux, e especialmente
> +para mantenedores de subsistemas. Ele contém um subconjunto das informações
> +discutidas no guia mais geral "`Protegendo a Integridade do Código`_" publicado pela
> +Linux Foundation. Leia esse documento para uma discussão mais aprofundada sobre
> +alguns dos tópicos mencionados neste guia.
> +
> +.. _`Protegendo a Integridade do Código`: https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md
> +
> +O papel do PGP no desenvolvimento do Kernel Linux
> +=================================================
> +
> +O PGP ajuda a garantir a integridade do código que é produzido pela comunidade
> +de desenvolvimento do kernel Linux e, em menor grau, a estabelecer canais de
> +comunicação confiáveis entre desenvolvedores por meio da troca de e-mails
> +assinados com PGP.
> +
> +O código-fonte do kernel Linux está disponível em dois formatos principais:
> +
> +- Repositórios de fontes distribuídos (git)
> +- Snapshots de lançamentos periódicos (tarballs)
Here, the original text is:
- Periodic release snapshots (tarballs)
Which is OK on English, but the translation itself sounded
meaningless to my eyes. Also, IMO "release" should not be translated
to plural. Ok, this one is hard as there's no equivalent on Portuguese
to "snapshots" or "tarballs".
Maybe:
Arquivos de release periódicos (tarballs)
or:
Arquivos de release (tarballs)
or, maybe even clearer:
Arquivos tarballs por release
--
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH V9 5/8] dax: Add dax_operations for use by fs-dax on fsdev dax
From: John Groves @ 2026-03-27 14:06 UTC (permalink / raw)
To: Dave Jiang
Cc: John Groves, Miklos Szeredi, Dan Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Matthew Wilcox, Jan Kara, Alexander Viro,
David Hildenbrand, Christian Brauner, Darrick J . Wong,
Randy Dunlap, Jeff Layton, Amir Goldstein, Jonathan Cameron,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <593b2b5c-779b-4e29-8b03-12ce743b10b4@intel.com>
On 26/03/25 02:28PM, Dave Jiang wrote:
>
>
> On 3/23/26 5:39 PM, John Groves wrote:
> > From: John Groves <John@Groves.net>
> >
> > fsdev: Add dax_operations for use by famfs.
> >
> > This replicates the functionality from drivers/nvdimm/pmem.c that
> > conventional fs-dax file systems (e.g. xfs) use to support dax
> > read/write/mmap to a daxdev - without which famfs can't sit atop a
> > daxdev.
> >
> > - These methods are based on pmem_dax_ops from drivers/nvdimm/pmem.c
> > - fsdev_dax_direct_access() returns the hpa, pfn and kva. The kva was
> > newly stored as dev_dax->virt_addr by dev_dax_probe().
> > - The hpa/pfn are used for mmap (dax_iomap_fault()), and the kva is used
> > for read/write (dax_iomap_rw())
> > - fsdev_dax_recovery_write() and dev_dax_zero_page_range() have not been
> > tested yet. I'm looking for suggestions as to how to test those.
> > - dax-private.h: add dev_dax->cached_size, which fsdev needs to
> > remember. The dev_dax size cannot change while a driver is bound
> > (dev_dax_resize returns -EBUSY if dev->driver is set). Caching the size
> > at probe time allows fsdev's direct_access path can use it without
> > acquiring dax_dev_rwsem (which isn't exported anyway).
> >
> > Signed-off-by: John Groves <john@groves.net>
> > ---
> > drivers/dax/dax-private.h | 1 +
> > drivers/dax/fsdev.c | 84 +++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 85 insertions(+)
> >
> > diff --git a/drivers/dax/dax-private.h b/drivers/dax/dax-private.h
> > index 7a3727d76a68..ee8f3af8387f 100644
> > --- a/drivers/dax/dax-private.h
> > +++ b/drivers/dax/dax-private.h
> > @@ -85,6 +85,7 @@ struct dev_dax {
> > struct dax_region *region;
> > struct dax_device *dax_dev;
> > void *virt_addr;
> > + u64 cached_size;
>
> Just caught this. Need a kdoc entry.
>
> DJ
Thank you! Added for v10
John
^ permalink raw reply
* Re: [PATCH V9 5/8] dax: Add dax_operations for use by fs-dax on fsdev dax
From: John Groves @ 2026-03-27 14:14 UTC (permalink / raw)
To: Dave Jiang
Cc: John Groves, Miklos Szeredi, Dan Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Matthew Wilcox, Jan Kara, Alexander Viro,
David Hildenbrand, Christian Brauner, Darrick J . Wong,
Randy Dunlap, Jeff Layton, Amir Goldstein, Jonathan Cameron,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <d4461e56-8a4d-4d2c-8de9-23a265dc617f@intel.com>
On 26/03/25 03:40PM, Dave Jiang wrote:
>
>
> On 3/23/26 5:39 PM, John Groves wrote:
> > From: John Groves <John@Groves.net>
> >
> > fsdev: Add dax_operations for use by famfs.
> >
> > This replicates the functionality from drivers/nvdimm/pmem.c that
> > conventional fs-dax file systems (e.g. xfs) use to support dax
> > read/write/mmap to a daxdev - without which famfs can't sit atop a
> > daxdev.
> >
> > - These methods are based on pmem_dax_ops from drivers/nvdimm/pmem.c
> > - fsdev_dax_direct_access() returns the hpa, pfn and kva. The kva was
> > newly stored as dev_dax->virt_addr by dev_dax_probe().
> > - The hpa/pfn are used for mmap (dax_iomap_fault()), and the kva is used
> > for read/write (dax_iomap_rw())
> > - fsdev_dax_recovery_write() and dev_dax_zero_page_range() have not been
> > tested yet. I'm looking for suggestions as to how to test those.
> > - dax-private.h: add dev_dax->cached_size, which fsdev needs to
> > remember. The dev_dax size cannot change while a driver is bound
> > (dev_dax_resize returns -EBUSY if dev->driver is set). Caching the size
> > at probe time allows fsdev's direct_access path can use it without
> > acquiring dax_dev_rwsem (which isn't exported anyway).
> >
> > Signed-off-by: John Groves <john@groves.net>
>
> Couple nits below while I'm stealing code from you.
:D
>
> > ---
> > drivers/dax/dax-private.h | 1 +
> > drivers/dax/fsdev.c | 84 +++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 85 insertions(+)
> >
> > diff --git a/drivers/dax/dax-private.h b/drivers/dax/dax-private.h
> > index 7a3727d76a68..ee8f3af8387f 100644
> > --- a/drivers/dax/dax-private.h
> > +++ b/drivers/dax/dax-private.h
> > @@ -85,6 +85,7 @@ struct dev_dax {
> > struct dax_region *region;
> > struct dax_device *dax_dev;
> > void *virt_addr;
> > + u64 cached_size;
> > unsigned int align;
> > int target_node;
> > bool dyn_id;
> > diff --git a/drivers/dax/fsdev.c b/drivers/dax/fsdev.c
> > index c75478d3d548..be3d2b0e8418 100644
> > --- a/drivers/dax/fsdev.c
> > +++ b/drivers/dax/fsdev.c
> > @@ -28,6 +28,85 @@
> > * - No mmap support - all access is through fs-dax/iomap
> > */
> >
> > +static void fsdev_write_dax(void *pmem_addr, struct page *page,
>
> addr instead of pmem_addr? copy pasta error?
Yep, fixed thanks
>
> > + unsigned int off, unsigned int len)
> > +{
> > + while (len) {
> > + void *mem = kmap_local_page(page);
> > + unsigned int chunk = min_t(unsigned int, len, PAGE_SIZE - off);
> > +
> > + memcpy_flushcache(pmem_addr, mem + off, chunk);
> > + kunmap_local(mem);
> > + len -= chunk;
> > + off = 0;
> > + page++;
> > + pmem_addr += chunk;
> > + }
> > +}
> > +
> > +static long __fsdev_dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff,
> > + long nr_pages, enum dax_access_mode mode, void **kaddr,
> > + unsigned long *pfn)
> > +{
> > + struct dev_dax *dev_dax = dax_get_private(dax_dev);
> > + size_t size = nr_pages << PAGE_SHIFT;
> > + size_t offset = pgoff << PAGE_SHIFT;
> > + void *virt_addr = dev_dax->virt_addr + offset;
> > + phys_addr_t phys;
> > + unsigned long local_pfn;
> > +
> > + phys = dax_pgoff_to_phys(dev_dax, pgoff, nr_pages << PAGE_SHIFT);
>
> you can use 'size' instead here since it's previously computed already.
>
> DJ
Indeed - thanks!
John
^ permalink raw reply
* Re: [PATCH v2] bootconfig: Apply early options from embedded config
From: Masami Hiramatsu @ 2026-03-27 14:16 UTC (permalink / raw)
To: Breno Leitao
Cc: Jonathan Corbet, Shuah Khan, linux-kernel, linux-trace-kernel,
linux-doc, oss, paulmck, rostedt, kernel-team
In-Reply-To: <acZX_IXQiGwMMi5e@gmail.com>
On Fri, 27 Mar 2026 03:18:31 -0700
Breno Leitao <leitao@debian.org> wrote:
> On Thu, Mar 26, 2026 at 11:30:42PM +0900, Masami Hiramatsu wrote:
> > On Wed, 25 Mar 2026 23:22:04 +0900
> > Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> >
> > > > + /*
> > > > + * Keys that do not match any early_param() handler are silently
> > > > + * ignored — do_early_param() always returns 0.
> > > > + */
> > > > + xbc_node_for_each_key_value(root, knode, val) {
> > >
> > > [sashiko comment]
> > > | Does this loop handle array values correctly?
> > > | xbc_node_for_each_key_value() only assigns the first value of an array to
> > > | the val pointer before advancing to the next key. It does not iterate over
> > > | the child nodes of the array.
> > > | If the bootconfig contains a multi-value key like
> > > | kernel.console = "ttyS0", "tty0", will the subsequent values in the array
> > > | be silently dropped instead of passed to the early_param handlers?
> > >
> > > Also, good catch :) we need to use xbc_node_for_each_array_value()
> > > for inner loop.
> >
> > FYI, xbc_snprint_cmdline() translates the arraied parameter as
> > multiple parameters. For example,
> >
> > foo = bar, buz;
> >
> > will be converted to
> >
> > foo=bar foo=buz
> >
> > Thus, I think we should do the same thing below;
> >
> > >
> > > > + if (xbc_node_compose_key_after(root, knode, xbc_namebuf, XBC_KEYLEN_MAX) < 0)
> > > > + continue;
> > > > +
> > > > + /*
> > > > + * We need to copy const char *val to a char pointer,
> > > > + * which is what do_early_param() need, given it might
> > > > + * call strsep(), strtok() later.
> > > > + */
> > > > + ret = strscpy(val_buf, val, sizeof(val_buf));
> > > > + if (ret < 0) {
> > > > + pr_warn("ignoring bootconfig value '%s', too long\n",
> > > > + xbc_namebuf);
> > > > + continue;
> > > > + }
> > > > + do_early_param(xbc_namebuf, val_buf, NULL, NULL);
> >
> > So instead of this;
> >
> > xbc_array_for_each_value(vnode, val) {
> > do_early_param(xbc_namebuf, val, NULL, NULL);
> > }
> >
> > Maybe it is a good timing to recondier unifying kernel cmdline and bootconfig
> > from API viewpoint.
>
> I'm not familiar with the history on this topic. Has unifying the APIs been
> previously considered and set aside?
Previously I considered but I found some early parameters must be composed by
bootloaders, and they does not support bootconfig. Thus, I introduced
setup_boot_config() to compose kernel.* parameters into cmdline buffer.
>
> Given all the feedback on this series, I see three types of issues to address:
>
> 1) Minor patch improvements
> 2) Architecture-specific super early parameters being parsed before bootconfig
> is available
> 3) Unifying kernel cmdline and bootconfig interfaces
I think we can start with 1) for embedded bootconfig for this series
with using bootconfig in parse_early_param().
For 2), I think it needs to check which parameters are expected to
be passed by bootloaders, which does not care bootconfig currently.
For 3), eventually it may be need to change how kernel handle the
parameters. I think I need to introduce CONFIG_BOOT_CONFIG_EXPOSED
option which keeps the xbc_*() API and parsed data accessible after
boot (Remove __init) and exposed to modules, so that all modules
can use xbc_* to get parameters from bootconfig directly.
Thanks,
>
> Which of these areas would you recommend I prioritize?
>
> Thanks for the guidance,
> --breno
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64/kvm: Enable eager hugepage splitting if HDBSS is available
From: Leonardo Bras @ 2026-03-27 14:37 UTC (permalink / raw)
To: Tian Zheng
Cc: Leonardo Bras, maz, oupton, catalin.marinas, corbet, pbonzini,
will, yuzenghui, wangzhou1, liuyonglong, Jonathan.Cameron,
yezhenyu2, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-doc, linux-kernel, skhan, suzuki.poulose
In-Reply-To: <6cce203f-89d9-4e9d-8b28-9629eb53b180@huawei.com>
On Fri, Mar 27, 2026 at 03:40:30PM +0800, Tian Zheng wrote:
>
> On 3/26/2026 2:20 AM, Leonardo Bras wrote:
> > FEAT_HDBSS speeds up guest memory dirty tracking by avoiding a page fault
> > and saving the entry in a tracking structure.
> >
> > That may be a problem when we have guest memory backed by hugepages or
> > transparent huge pages, as it's not possible to do on-demand hugepage
> > splitting, relying only on eager hugepage splitting.
> >
> > So, at stage2 initialization, enable eager hugepage splitting with
> > chunk = PAGE_SIZE if the system supports HDBSS.
> >
> > Signed-off-by: Leonardo Bras <leo.bras@arm.com>
> > ---
> > arch/arm64/kvm/mmu.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 070a01e53fcb..bdfa72b7c073 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -993,22 +993,26 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu, unsigned long t
> > mmu->last_vcpu_ran = alloc_percpu(typeof(*mmu->last_vcpu_ran));
> > if (!mmu->last_vcpu_ran) {
> > err = -ENOMEM;
> > goto out_destroy_pgtable;
> > }
> > for_each_possible_cpu(cpu)
> > *per_cpu_ptr(mmu->last_vcpu_ran, cpu) = -1;
> > - /* The eager page splitting is disabled by default */
> > - mmu->split_page_chunk_size = KVM_ARM_EAGER_SPLIT_CHUNK_SIZE_DEFAULT;
> > + /* The eager page splitting is disabled by default if system has no HDBSS */
> > + if (system_supports_hacdbs())
> > + mmu->split_page_chunk_size = PAGE_SIZE;
> > + else
> > + mmu->split_page_chunk_size = KVM_ARM_EAGER_SPLIT_CHUNK_SIZE_DEFAULT;
> > +
> > mmu->split_page_cache.gfp_zero = __GFP_ZERO;
> > mmu->pgd_phys = __pa(pgt->pgd);
> > if (kvm_is_nested_s2_mmu(kvm, mmu))
> > kvm_init_nested_s2_mmu(mmu);
> > return 0;
> > out_destroy_pgtable:
>
>
> Thanks again for sending this patch. I'll integrate it into the next version
> and run some tests.
>
>
Awesome, thanks!
Leo
^ permalink raw reply
* Re: [PATCH V9 7/8] dax: Add fs_dax_get() func to prepare dax for fs-dax usage
From: John Groves @ 2026-03-27 14:45 UTC (permalink / raw)
To: Jonathan Cameron
Cc: John Groves, Miklos Szeredi, Dan Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Darrick J . Wong, Randy Dunlap, Jeff Layton, Amir Goldstein,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <20260324150526.000047b6@huawei.com>
On 26/03/24 03:05PM, Jonathan Cameron wrote:
> On Tue, 24 Mar 2026 00:39:31 +0000
> John Groves <john@jagalactic.com> wrote:
>
> > From: John Groves <john@groves.net>
> >
> > The fs_dax_get() function should be called by fs-dax file systems after
> > opening a fsdev dax device. This adds holder_operations, which provides
> > a memory failure callback path and effects exclusivity between callers
> > of fs_dax_get().
> >
> > fs_dax_get() is specific to fsdev_dax, so it checks the driver type
> > (which required touching bus.[ch]). fs_dax_get() fails if fsdev_dax is
> > not bound to the memory.
> >
> > This function serves the same role as fs_dax_get_by_bdev(), which dax
> > file systems call after opening the pmem block device.
> >
> > This can't be located in fsdev.c because struct dax_device is opaque
> > there.
> >
> > This will be called by fs/fuse/famfs.c in a subsequent commit.
> >
> > Signed-off-by: John Groves <john@groves.net>
> Hi John,
>
> Looks like a stray header change - see inline.
>
> With that tidied up.
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
>
> > #define dax_driver_register(driver) \
> > diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> > index ba0b4cd18a77..d4ab60c406bf 100644
> > --- a/drivers/dax/super.c
> > +++ b/drivers/dax/super.c
>
> > diff --git a/include/linux/dax.h b/include/linux/dax.h
> > index b19bfe0c2fd1..bf37b9a982f3 100644
> > --- a/include/linux/dax.h
> > +++ b/include/linux/dax.h
>
> > #if IS_ENABLED(CONFIG_FS_DAX)
> > +void fs_put_dax(struct dax_device *dax_dev, void *holder);
> > +int fs_dax_get(struct dax_device *dax_dev, void *holder,
> > + const struct dax_holder_operations *hops);
> > +struct dax_device *inode_dax(struct inode *inode);
>
> What's this? Not used in this patch and not stubbed.
> It's in drivers/dax/dax-private.h already and given I assume code builds
> before this patch (and it's not used in patch 8) then presumably it doesn't
> need to be here.
>
> I got suspicious due to the lack of stub rather indicating something differnt
> form the other two.
Dropped, thanks!
John
^ permalink raw reply
* Re: [PATCH V9 01/10] famfs_fuse: Update macro s/FUSE_IS_DAX/FUSE_IS_VIRTIO_DAX/
From: John Groves @ 2026-03-27 14:52 UTC (permalink / raw)
To: Jonathan Cameron
Cc: John Groves, Miklos Szeredi, Dan Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Darrick J . Wong, Randy Dunlap, Jeff Layton, Amir Goldstein,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <20260324151253.00006b86@huawei.com>
On 26/03/24 03:12PM, Jonathan Cameron wrote:
> On Tue, 24 Mar 2026 00:40:36 +0000
> John Groves <john@jagalactic.com> wrote:
>
> > From: John Groves <john@groves.net>
> >
> > Virtio_fs now needs to determine if an inode is DAX && not famfs.
> FWIW patch bundles broke sashiko
>
> https://sashiko.dev/#/message/0100019d1d46d094-cc0a4b79-3bd2-43e8-a08d-ab8cd21266a6-000000%40email.amazonses.com
> It only reviewed the fuse part. (I was looking to see what it had found I missed
> in the DAX ones).
> > This relaces the FUSE_IS_DAX() macro with FUSE_IS_VIRTIO_DAX(),
>
> replaces (Sashiko spell checks ;)
Derp. With v10 I will just post separate series'
>
> > in preparation for famfs in later commits. The dummy
> > fuse_file_famfs() macro will be replaced with a working
> > function.
> >
> > Reviewed-by: Joanne Koong <joannelkoong@gmail.com>
> > Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> > Signed-off-by: John Groves <john@groves.net>
>
>
>
> > ---
> > fs/fuse/dir.c | 2 +-
> > fs/fuse/file.c | 13 ++++++++-----
> > fs/fuse/fuse_i.h | 9 ++++++++-
> > fs/fuse/inode.c | 4 ++--
> > fs/fuse/iomode.c | 2 +-
> > 5 files changed, 20 insertions(+), 10 deletions(-)
> >
> > diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
> > index 7ac6b232ef12..c63f097bc697 100644
> > --- a/fs/fuse/dir.c
> > +++ b/fs/fuse/dir.c
> > @@ -2161,7 +2161,7 @@ int fuse_do_setattr(struct mnt_idmap *idmap, struct dentry *dentry,
> > is_truncate = true;
> > }
> >
> > - if (FUSE_IS_DAX(inode) && is_truncate) {
> > + if (FUSE_IS_VIRTIO_DAX(fi) && is_truncate) {
> > filemap_invalidate_lock(mapping);
> > fault_blocked = true;
> > err = fuse_dax_break_layouts(inode, 0, -1);
> > diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> > index b1bb7153cb78..4ee5065737d8 100644
> > --- a/fs/fuse/file.c
> > +++ b/fs/fuse/file.c
> > @@ -252,7 +252,7 @@ static int fuse_open(struct inode *inode, struct file *file)
> > int err;
> > bool is_truncate = (file->f_flags & O_TRUNC) && fc->atomic_o_trunc;
> > bool is_wb_truncate = is_truncate && fc->writeback_cache;
> > - bool dax_truncate = is_truncate && FUSE_IS_DAX(inode);
> > + bool dax_truncate = is_truncate && FUSE_IS_VIRTIO_DAX(fi);
> >
> > if (fuse_is_bad(inode))
> > return -EIO;
> > @@ -1812,11 +1812,12 @@ static ssize_t fuse_file_read_iter(struct kiocb *iocb, struct iov_iter *to)
> > struct file *file = iocb->ki_filp;
> > struct fuse_file *ff = file->private_data;
> > struct inode *inode = file_inode(file);
> > + struct fuse_inode *fi = get_fuse_inode(inode);
> >
> > if (fuse_is_bad(inode))
> > return -EIO;
> >
> > - if (FUSE_IS_DAX(inode))
> > + if (FUSE_IS_VIRTIO_DAX(fi))
> > return fuse_dax_read_iter(iocb, to);
> >
> > /* FOPEN_DIRECT_IO overrides FOPEN_PASSTHROUGH */
> > @@ -1833,11 +1834,12 @@ static ssize_t fuse_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
> > struct file *file = iocb->ki_filp;
> > struct fuse_file *ff = file->private_data;
> > struct inode *inode = file_inode(file);
> > + struct fuse_inode *fi = get_fuse_inode(inode);
> >
> > if (fuse_is_bad(inode))
> > return -EIO;
> >
> > - if (FUSE_IS_DAX(inode))
> > + if (FUSE_IS_VIRTIO_DAX(fi))
> > return fuse_dax_write_iter(iocb, from);
> >
> > /* FOPEN_DIRECT_IO overrides FOPEN_PASSTHROUGH */
> > @@ -2370,10 +2372,11 @@ static int fuse_file_mmap(struct file *file, struct vm_area_struct *vma)
> > struct fuse_file *ff = file->private_data;
> > struct fuse_conn *fc = ff->fm->fc;
> > struct inode *inode = file_inode(file);
> > + struct fuse_inode *fi = get_fuse_inode(inode);
> > int rc;
> >
> > /* DAX mmap is superior to direct_io mmap */
> > - if (FUSE_IS_DAX(inode))
> > + if (FUSE_IS_VIRTIO_DAX(fi))
> > return fuse_dax_mmap(file, vma);
> >
> > /*
> > @@ -2934,7 +2937,7 @@ static long fuse_file_fallocate(struct file *file, int mode, loff_t offset,
> > .mode = mode
> > };
> > int err;
> > - bool block_faults = FUSE_IS_DAX(inode) &&
> > + bool block_faults = FUSE_IS_VIRTIO_DAX(fi) &&
> > (!(mode & FALLOC_FL_KEEP_SIZE) ||
> > (mode & (FALLOC_FL_PUNCH_HOLE | FALLOC_FL_ZERO_RANGE)));
> >
> > diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
> > index 7f16049387d1..45e108dec771 100644
> > --- a/fs/fuse/fuse_i.h
> > +++ b/fs/fuse/fuse_i.h
> > @@ -1508,7 +1508,14 @@ void fuse_free_conn(struct fuse_conn *fc);
> >
> > /* dax.c */
> >
> > -#define FUSE_IS_DAX(inode) (IS_ENABLED(CONFIG_FUSE_DAX) && IS_DAX(inode))
> > +static inline bool fuse_file_famfs(struct fuse_inode *fuse_inode) /* Will be superseded */
> > +{
> > + (void)fuse_inode;
> > + return false;
> > +}
> > +#define FUSE_IS_VIRTIO_DAX(fuse_inode) (IS_ENABLED(CONFIG_FUSE_DAX) \
> > + && IS_DAX(&fuse_inode->inode) \
> > + && !fuse_file_famfs(fuse_inode))
>
> The AI overlord pointed out you should probably have a few more brackets
> just in case someone passes something odd in as fuse_inode. Lets assume
> they don't pass things with side effects in.
>
> #define FUSE_IS_VIRTIO_DAX(fuse_inode) (IS_ENABLED(CONFIG_FUSE_DAX) \
> && IS_DAX(&(fuse_inode)->inode) \
> && !fuse_file_famfs(fuse_inode))
>
Thank you for your tokens ;)
Fixed - and now there is a change for the v10 fuse series
John
^ permalink raw reply
* Re: [PATCH v3 4/5] KVM: arm64: Enable HDBSS support and handle HDBSSF events
From: Leonardo Bras @ 2026-03-27 15:00 UTC (permalink / raw)
To: Tian Zheng
Cc: Leonardo Bras, maz, oupton, catalin.marinas, corbet, pbonzini,
will, yuzenghui, wangzhou1, liuyonglong, Jonathan.Cameron,
yezhenyu2, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-doc, linux-kernel, skhan, suzuki.poulose
In-Reply-To: <e3253959-0340-4c13-a980-a599e090a6de@huawei.com>
On Fri, Mar 27, 2026 at 03:35:29PM +0800, Tian Zheng wrote:
>
> On 3/26/2026 2:05 AM, Leonardo Bras wrote:
> > Hello Tian,
> >
> > I am currently working on HACDBS enablement(which will be rebased on top of
> > this patchset) and due to the fact HACDBS and HDBSS are kind of
> > complementary I will sometimes come with some questions for issues I have
> > faced myself on that part. :)
> >
> > (see below)
>
>
> Of course! Happy to exchange ideas and learn together.
:)
>
>
> >
> > On Wed, Feb 25, 2026 at 12:04:20PM +0800, Tian Zheng wrote:
> > > From: eillon <yezhenyu2@huawei.com>
> > >
> > > HDBSS is enabled via an ioctl from userspace (e.g. QEMU) at the start of
> > > migration. This feature is only supported in VHE mode.
> > >
> > > Initially, S2 PTEs doesn't contain the DBM attribute. During migration,
> > > write faults are handled by user_mem_abort, which relaxes permissions
> > > and adds the DBM bit when HDBSS is active. Once DBM is set, subsequent
> > > writes no longer trap, as the hardware automatically transitions the page
> > > from writable-clean to writable-dirty.
> > >
> > > KVM does not scan S2 page tables to consume DBM. Instead, when HDBSS is
> > > enabled, the hardware observes the clean->dirty transition and records
> > > the corresponding page into the HDBSS buffer.
> > >
> > > During sync_dirty_log, KVM kicks all vCPUs to force VM-Exit, ensuring
> > > that check_vcpu_requests flushes the HDBSS buffer and propagates the
> > > accumulated dirty information into the userspace-visible dirty bitmap.
> > >
> > > Add fault handling for HDBSS including buffer full, external abort, and
> > > general protection fault (GPF).
> > >
> > > Signed-off-by: eillon <yezhenyu2@huawei.com>
> > > Signed-off-by: Tian Zheng <zhengtian10@huawei.com>
> > > ---
> > > arch/arm64/include/asm/esr.h | 5 ++
> > > arch/arm64/include/asm/kvm_host.h | 17 +++++
> > > arch/arm64/include/asm/kvm_mmu.h | 1 +
> > > arch/arm64/include/asm/sysreg.h | 11 ++++
> > > arch/arm64/kvm/arm.c | 102 ++++++++++++++++++++++++++++++
> > > arch/arm64/kvm/hyp/vhe/switch.c | 19 ++++++
> > > arch/arm64/kvm/mmu.c | 70 ++++++++++++++++++++
> > > arch/arm64/kvm/reset.c | 3 +
> > > 8 files changed, 228 insertions(+)
> > >
> > > diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
> > > index 81c17320a588..2e6b679b5908 100644
> > > --- a/arch/arm64/include/asm/esr.h
> > > +++ b/arch/arm64/include/asm/esr.h
> > > @@ -437,6 +437,11 @@
> > > #ifndef __ASSEMBLER__
> > > #include <asm/types.h>
> > >
> > > +static inline bool esr_iss2_is_hdbssf(unsigned long esr)
> > > +{
> > > + return ESR_ELx_ISS2(esr) & ESR_ELx_HDBSSF;
> > > +}
> > > +
> > > static inline unsigned long esr_brk_comment(unsigned long esr)
> > > {
> > > return esr & ESR_ELx_BRK64_ISS_COMMENT_MASK;
> > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > index 5d5a3bbdb95e..57ee6b53e061 100644
> > > --- a/arch/arm64/include/asm/kvm_host.h
> > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > @@ -55,12 +55,17 @@
> > > #define KVM_REQ_GUEST_HYP_IRQ_PENDING KVM_ARCH_REQ(9)
> > > #define KVM_REQ_MAP_L1_VNCR_EL2 KVM_ARCH_REQ(10)
> > > #define KVM_REQ_VGIC_PROCESS_UPDATE KVM_ARCH_REQ(11)
> > > +#define KVM_REQ_FLUSH_HDBSS KVM_ARCH_REQ(12)
> > >
> > > #define KVM_DIRTY_LOG_MANUAL_CAPS (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE | \
> > > KVM_DIRTY_LOG_INITIALLY_SET)
> > >
> > > #define KVM_HAVE_MMU_RWLOCK
> > >
> > > +/* HDBSS entry field definitions */
> > > +#define HDBSS_ENTRY_VALID BIT(0)
> > > +#define HDBSS_ENTRY_IPA GENMASK_ULL(55, 12)
> > > +
> > > /*
> > > * Mode of operation configurable with kvm-arm.mode early param.
> > > * See Documentation/admin-guide/kernel-parameters.txt for more information.
> > > @@ -84,6 +89,7 @@ int __init kvm_arm_init_sve(void);
> > > u32 __attribute_const__ kvm_target_cpu(void);
> > > void kvm_reset_vcpu(struct kvm_vcpu *vcpu);
> > > void kvm_arm_vcpu_destroy(struct kvm_vcpu *vcpu);
> > > +void kvm_arm_vcpu_free_hdbss(struct kvm_vcpu *vcpu);
> > >
> > > struct kvm_hyp_memcache {
> > > phys_addr_t head;
> > > @@ -405,6 +411,8 @@ struct kvm_arch {
> > > * the associated pKVM instance in the hypervisor.
> > > */
> > > struct kvm_protected_vm pkvm;
> > > +
> > > + bool enable_hdbss;
> > > };
> > >
> > > struct kvm_vcpu_fault_info {
> > > @@ -816,6 +824,12 @@ struct vcpu_reset_state {
> > > bool reset;
> > > };
> > >
> > > +struct vcpu_hdbss_state {
> > > + phys_addr_t base_phys;
> > > + u32 size;
> > > + u32 next_index;
> > > +};
> > > +
> > > struct vncr_tlb;
> > >
> > > struct kvm_vcpu_arch {
> > > @@ -920,6 +934,9 @@ struct kvm_vcpu_arch {
> > >
> > > /* Per-vcpu TLB for VNCR_EL2 -- NULL when !NV */
> > > struct vncr_tlb *vncr_tlb;
> > > +
> > > + /* HDBSS registers info */
> > > + struct vcpu_hdbss_state hdbss;
> > > };
> > >
> > > /*
> > > diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> > > index d968aca0461a..3fea8cfe8869 100644
> > > --- a/arch/arm64/include/asm/kvm_mmu.h
> > > +++ b/arch/arm64/include/asm/kvm_mmu.h
> > > @@ -183,6 +183,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
> > >
> > > int kvm_handle_guest_sea(struct kvm_vcpu *vcpu);
> > > int kvm_handle_guest_abort(struct kvm_vcpu *vcpu);
> > > +void kvm_flush_hdbss_buffer(struct kvm_vcpu *vcpu);
> > >
> > > phys_addr_t kvm_mmu_get_httbr(void);
> > > phys_addr_t kvm_get_idmap_vector(void);
> > > diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> > > index f4436ecc630c..d11f4d0dd4e7 100644
> > > --- a/arch/arm64/include/asm/sysreg.h
> > > +++ b/arch/arm64/include/asm/sysreg.h
> > > @@ -1039,6 +1039,17 @@
> > >
> > > #define GCS_CAP(x) ((((unsigned long)x) & GCS_CAP_ADDR_MASK) | \
> > > GCS_CAP_VALID_TOKEN)
> > > +
> > > +/*
> > > + * Definitions for the HDBSS feature
> > > + */
> > > +#define HDBSS_MAX_SIZE HDBSSBR_EL2_SZ_2MB
> > > +
> > > +#define HDBSSBR_EL2(baddr, sz) (((baddr) & GENMASK(55, 12 + sz)) | \
> > > + FIELD_PREP(HDBSSBR_EL2_SZ_MASK, sz))
> > > +
> > > +#define HDBSSPROD_IDX(prod) FIELD_GET(HDBSSPROD_EL2_INDEX_MASK, prod)
> > > +
> > > /*
> > > * Definitions for GICv5 instructions]
> > > */
> > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > > index 29f0326f7e00..d64da05e25c4 100644
> > > --- a/arch/arm64/kvm/arm.c
> > > +++ b/arch/arm64/kvm/arm.c
> > > @@ -125,6 +125,87 @@ int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
> > > return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE;
> > > }
> > >
> > > +void kvm_arm_vcpu_free_hdbss(struct kvm_vcpu *vcpu)
> > > +{
> > > + struct page *hdbss_pg;
> > > +
> > > + hdbss_pg = phys_to_page(vcpu->arch.hdbss.base_phys);
> > > + if (hdbss_pg)
> > > + __free_pages(hdbss_pg, vcpu->arch.hdbss.size);
> > > +
> > > + vcpu->arch.hdbss.size = 0;
> > > +}
> > > +
> > > +static int kvm_cap_arm_enable_hdbss(struct kvm *kvm,
> > > + struct kvm_enable_cap *cap)
> > > +{
> > > + unsigned long i;
> > > + struct kvm_vcpu *vcpu;
> > > + struct page *hdbss_pg = NULL;
> > > + __u64 size = cap->args[0];
> > > + bool enable = cap->args[1] ? true : false;
> > > +
> > > + if (!system_supports_hdbss())
> > > + return -EINVAL;
> > > +
> > > + if (size > HDBSS_MAX_SIZE)
> > > + return -EINVAL;
> > > +
> > > + if (!enable && !kvm->arch.enable_hdbss) /* Already Off */
> > > + return 0;
> > > +
> > > + if (enable && kvm->arch.enable_hdbss) /* Already On, can't set size */
> > > + return -EINVAL;
> > > +
> > > + if (!enable) { /* Turn it off */
> > > + kvm->arch.mmu.vtcr &= ~(VTCR_EL2_HD | VTCR_EL2_HDBSS | VTCR_EL2_HA);
> > > +
> > > + kvm_for_each_vcpu(i, vcpu, kvm) {
> > > + /* Kick vcpus to flush hdbss buffer. */
> > > + kvm_vcpu_kick(vcpu);
> > > +
> > > + kvm_arm_vcpu_free_hdbss(vcpu);
> > > + }
> > > +
> > > + kvm->arch.enable_hdbss = false;
> > > +
> > > + return 0;
> > > + }
> > > +
> > > + /* Turn it on */
> > > + kvm_for_each_vcpu(i, vcpu, kvm) {
> > > + hdbss_pg = alloc_pages(GFP_KERNEL_ACCOUNT, size);
> > > + if (!hdbss_pg)
> > > + goto error_alloc;
> > > +
> > > + vcpu->arch.hdbss = (struct vcpu_hdbss_state) {
> > > + .base_phys = page_to_phys(hdbss_pg),
> > > + .size = size,
> > > + .next_index = 0,
> > > + };
> > > + }
> > > +
> > > + kvm->arch.enable_hdbss = true;
> > > + kvm->arch.mmu.vtcr |= VTCR_EL2_HD | VTCR_EL2_HDBSS | VTCR_EL2_HA;
> > > +
> > > + /*
> > > + * We should kick vcpus out of guest mode here to load new
> > > + * vtcr value to vtcr_el2 register when re-enter guest mode.
> > > + */
> > > + kvm_for_each_vcpu(i, vcpu, kvm)
> > > + kvm_vcpu_kick(vcpu);
> > > +
> > > + return 0;
> > > +
> > > +error_alloc:
> > > + kvm_for_each_vcpu(i, vcpu, kvm) {
> > > + if (vcpu->arch.hdbss.base_phys)
> > > + kvm_arm_vcpu_free_hdbss(vcpu);
> > > + }
> > > +
> > > + return -ENOMEM;
> > > +}
> > > +
> > > int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > > struct kvm_enable_cap *cap)
> > > {
> > > @@ -182,6 +263,11 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > > r = 0;
> > > set_bit(KVM_ARCH_FLAG_EXIT_SEA, &kvm->arch.flags);
> > > break;
> > > + case KVM_CAP_ARM_HW_DIRTY_STATE_TRACK:
> > > + mutex_lock(&kvm->lock);
> > > + r = kvm_cap_arm_enable_hdbss(kvm, cap);
> > > + mutex_unlock(&kvm->lock);
> > > + break;
> > > default:
> > > break;
> > > }
> > > @@ -471,6 +557,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > > r = kvm_supports_cacheable_pfnmap();
> > > break;
> > >
> > > + case KVM_CAP_ARM_HW_DIRTY_STATE_TRACK:
> > > + r = system_supports_hdbss();
> > > + break;
> > > default:
> > > r = 0;
> > > }
> > > @@ -1120,6 +1209,9 @@ static int check_vcpu_requests(struct kvm_vcpu *vcpu)
> > > if (kvm_dirty_ring_check_request(vcpu))
> > > return 0;
> > >
> > > + if (kvm_check_request(KVM_REQ_FLUSH_HDBSS, vcpu))
> > > + kvm_flush_hdbss_buffer(vcpu);
> > > +
> > > check_nested_vcpu_requests(vcpu);
> > > }
> > >
> > > @@ -1898,7 +1990,17 @@ long kvm_arch_vcpu_unlocked_ioctl(struct file *filp, unsigned int ioctl,
> > >
> > > void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot)
> > > {
> > > + /*
> > > + * Flush all CPUs' dirty log buffers to the dirty_bitmap. Called
> > > + * before reporting dirty_bitmap to userspace. Send a request with
> > > + * KVM_REQUEST_WAIT to flush buffer synchronously.
> > > + */
> > > + struct kvm_vcpu *vcpu;
> > > +
> > > + if (!kvm->arch.enable_hdbss)
> > > + return;
> > >
> > > + kvm_make_all_cpus_request(kvm, KVM_REQ_FLUSH_HDBSS);
> > > }
> > >
> > > static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm,
> > > diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
> > > index 9db3f11a4754..600cbc4f8ae9 100644
> > > --- a/arch/arm64/kvm/hyp/vhe/switch.c
> > > +++ b/arch/arm64/kvm/hyp/vhe/switch.c
> > > @@ -213,6 +213,23 @@ static void __vcpu_put_deactivate_traps(struct kvm_vcpu *vcpu)
> > > local_irq_restore(flags);
> > > }
> > >
> > > +static void __load_hdbss(struct kvm_vcpu *vcpu)
> > > +{
> > > + struct kvm *kvm = vcpu->kvm;
> > > + u64 br_el2, prod_el2;
> > > +
> > > + if (!kvm->arch.enable_hdbss)
> > > + return;
> > > +
> > > + br_el2 = HDBSSBR_EL2(vcpu->arch.hdbss.base_phys, vcpu->arch.hdbss.size);
> > > + prod_el2 = vcpu->arch.hdbss.next_index;
> > > +
> > > + write_sysreg_s(br_el2, SYS_HDBSSBR_EL2);
> > > + write_sysreg_s(prod_el2, SYS_HDBSSPROD_EL2);
> > > +
> > > + isb();
> > > +}
> > > +
> > I see in the code below you trust that the tracking will happen with
> > PAGE_SIZE granularity (you track with PAGE_SHIFT).
> >
> > That may be a problem when we have guest memory backed by hugepages or
> > transparent huge pages.
> >
> > When we are using HDBSS, there is no fault happening, so we have no way of
> > doing on-demand block splitting, so we need to make use of eager block
> > splitting, _before_ we start to track anything, or else we may have
> > different-sized pages in the HDBSS buffer, which is harder to deal with.
> >
> > Suggestion: do the eager splitting before we enable HDBSS.
> >
> > For this to happen, we have to enable the EAGER_SPLIT_CHUNK_SIZE
> > capability, which can only be enabled when all memslots are empty.
> >
> > I suggest doing that at kvm_init_stage2_mmu(), and checking if HDBSS is
> > in which case we set mmu->split_page_chunk_size to PAGESIZE.
> >
> > I will send a patch you can put before this one to make sure it works :)
> >
> > Thanks!
> > Leo
>
> Hi Leo,
>
> Thanks for the helpful suggestion. I had previously traced the
> hugepage-splitting path
>
> during live migration and found that when migration starts, enabling dirty
> logging
>
> triggers the splitting path. I also tested HDBSS with traditional hugepages
> and haven't
>
> observed any issues yet.
>
>
> However, your concern is valid — there may be cases not covered, especially
> when the
>
> VMM uses transparent hugepages. I'll integrate your patch into the next
> version and
>
> run some tests.
>
>
> For reference, here's the path I traced:
>
> ```
>
> - userspace, e.g., QEMU
>
> kvm_log_start
> +-> kvm_section_update_flags
> +-> kvm_slot_update_flags
> |
> | // For each memory region, QEMU issues a
> KVM_SET_USER_MEMORY_REGION ioctl.
> | // Before issuing it, flags are updated to include
> KVM_MEM_LOG_DIRTY_PAGES.
> +-> kvm_mem_flags
> +-> kvm_set_user_memory_region // ioctl that enables dirty logging
> on the memslot
>
> - KVM
>
> KVM_SET_USER_MEMORY_REGION
> +-> kvm_vm_ioctl_set_memory_region
> +-> kvm_set_memory_region / __kvm_set_memory_region
> +-> kvm_set_memslot
> +-> kvm_commit_memory_region
> +-> kvm_arch_commit_memory_region
> +-> kvm_mmu_split_memory_region
> // Splits Stage-2 hugepages/contiguous mappings into
> 4KB PTEs.
Right, except on a case we have dirty_log_manual_protect and init_set, when
it returns before splitting pages:
```
if (kvm_dirty_log_manual_protect_and_init_set(kvm))
return;
```
IIUC, that's desired to avoid holding the lock for a long time while it
cleans every page in the beginning, and instead do it in a per dirty-page
basis. I guess it may benefit guests with very little dirty pages, as it
does not have to split/dirty everything at the start.
(Its a pain for my HACDBS routines, though)
> +-> kvm_mmu_split_huge_pages
Other important point here:
You can see in this function it skips splitting if chunk_size == 0.
This value is set by a capability that configures EAGER_SPLIT, meaning
splitting before the guest have write faults, which is nice as the
write-fault is faster.
Two points in this capability:
- It's optional, if it's not set, only on-demand splitting (on fault) will
happen, and since HDBSS removes the write-fault, we have no splitting
- It can be set to any valid block size, not only 4K, nor PAGE_SIZE, it can
be set to PMD_SIZE, PUD_SIZE, and so on, which will depend on the
PAGE_SIZE the kernel was compiled to.
That's only some points to keep in mind :)
if (kvm_dirty_log_manual_protect_and_init_set(kvm))
return;
> +-> kvm_pgtable_stage2_split
>
> ```
>
> Thanks again for the detailed explanation and for sending the patch.
>
Thank you for the collaboration on this!
Leo
> > > void kvm_vcpu_load_vhe(struct kvm_vcpu *vcpu)
> > > {
> > > host_data_ptr(host_ctxt)->__hyp_running_vcpu = vcpu;
> > > @@ -220,10 +237,12 @@ void kvm_vcpu_load_vhe(struct kvm_vcpu *vcpu)
> > > __vcpu_load_switch_sysregs(vcpu);
> > > __vcpu_load_activate_traps(vcpu);
> > > __load_stage2(vcpu->arch.hw_mmu, vcpu->arch.hw_mmu->arch);
> > > + __load_hdbss(vcpu);
> > > }
> > >
> > > void kvm_vcpu_put_vhe(struct kvm_vcpu *vcpu)
> > > {
> > > + kvm_flush_hdbss_buffer(vcpu);
> > > __vcpu_put_deactivate_traps(vcpu);
> > > __vcpu_put_switch_sysregs(vcpu);
> > >
> > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > > index 070a01e53fcb..42b0710a16ce 100644
> > > --- a/arch/arm64/kvm/mmu.c
> > > +++ b/arch/arm64/kvm/mmu.c
> > > @@ -1896,6 +1896,9 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> > > if (writable)
> > > prot |= KVM_PGTABLE_PROT_W;
> > >
> > > + if (writable && kvm->arch.enable_hdbss && logging_active)
> > > + prot |= KVM_PGTABLE_PROT_DBM;
> > > +
> > > if (exec_fault)
> > > prot |= KVM_PGTABLE_PROT_X;
> > >
> > > @@ -2033,6 +2036,70 @@ int kvm_handle_guest_sea(struct kvm_vcpu *vcpu)
> > > return 0;
> > > }
> > >
> > > +void kvm_flush_hdbss_buffer(struct kvm_vcpu *vcpu)
> > > +{
> > > + int idx, curr_idx;
> > > + u64 br_el2;
> > > + u64 *hdbss_buf;
> > > + struct kvm *kvm = vcpu->kvm;
> > > +
> > > + if (!kvm->arch.enable_hdbss)
> > > + return;
> > > +
> > > + curr_idx = HDBSSPROD_IDX(read_sysreg_s(SYS_HDBSSPROD_EL2));
> > > + br_el2 = HDBSSBR_EL2(vcpu->arch.hdbss.base_phys, vcpu->arch.hdbss.size);
> > > +
> > > + /* Do nothing if HDBSS buffer is empty or br_el2 is NULL */
> > > + if (curr_idx == 0 || br_el2 == 0)
> > > + return;
> > > +
> > > + hdbss_buf = page_address(phys_to_page(vcpu->arch.hdbss.base_phys));
> > > + if (!hdbss_buf)
> > > + return;
> > > +
> > > + guard(write_lock_irqsave)(&vcpu->kvm->mmu_lock);
> > > + for (idx = 0; idx < curr_idx; idx++) {
> > > + u64 gpa;
> > > +
> > > + gpa = hdbss_buf[idx];
> > > + if (!(gpa & HDBSS_ENTRY_VALID))
> > > + continue;
> > > +
> > > + gpa &= HDBSS_ENTRY_IPA;
> > > + kvm_vcpu_mark_page_dirty(vcpu, gpa >> PAGE_SHIFT);
> > > + }
> > Here ^
>
> Thanks!
>
> Tian
>
>
> >
> > > +
> > > + /* reset HDBSS index */
> > > + write_sysreg_s(0, SYS_HDBSSPROD_EL2);
> > > + vcpu->arch.hdbss.next_index = 0;
> > > + isb();
> > > +}
> > > +
> > > +static int kvm_handle_hdbss_fault(struct kvm_vcpu *vcpu)
> > > +{
> > > + u64 prod;
> > > + u64 fsc;
> > > +
> > > + prod = read_sysreg_s(SYS_HDBSSPROD_EL2);
> > > + fsc = FIELD_GET(HDBSSPROD_EL2_FSC_MASK, prod);
> > > +
> > > + switch (fsc) {
> > > + case HDBSSPROD_EL2_FSC_OK:
> > > + /* Buffer full, which is reported as permission fault. */
> > > + kvm_flush_hdbss_buffer(vcpu);
> > > + return 1;
> > > + case HDBSSPROD_EL2_FSC_ExternalAbort:
> > > + case HDBSSPROD_EL2_FSC_GPF:
> > > + return -EFAULT;
> > > + default:
> > > + /* Unknown fault. */
> > > + WARN_ONCE(1,
> > > + "Unexpected HDBSS fault type, FSC: 0x%llx (prod=0x%llx, vcpu=%d)\n",
> > > + fsc, prod, vcpu->vcpu_id);
> > > + return -EFAULT;
> > > + }
> > > +}
> > > +
> > > /**
> > > * kvm_handle_guest_abort - handles all 2nd stage aborts
> > > * @vcpu: the VCPU pointer
> > > @@ -2071,6 +2138,9 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
> > >
> > > is_iabt = kvm_vcpu_trap_is_iabt(vcpu);
> > >
> > > + if (esr_iss2_is_hdbssf(esr))
> > > + return kvm_handle_hdbss_fault(vcpu);
> > > +
> > > if (esr_fsc_is_translation_fault(esr)) {
> > > /* Beyond sanitised PARange (which is the IPA limit) */
> > > if (fault_ipa >= BIT_ULL(get_kvm_ipa_limit())) {
> > > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> > > index 959532422d3a..c03a4b310b53 100644
> > > --- a/arch/arm64/kvm/reset.c
> > > +++ b/arch/arm64/kvm/reset.c
> > > @@ -161,6 +161,9 @@ void kvm_arm_vcpu_destroy(struct kvm_vcpu *vcpu)
> > > free_page((unsigned long)vcpu->arch.ctxt.vncr_array);
> > > kfree(vcpu->arch.vncr_tlb);
> > > kfree(vcpu->arch.ccsidr);
> > > +
> > > + if (vcpu->kvm->arch.enable_hdbss)
> > > + kvm_arm_vcpu_free_hdbss(vcpu);
> > > }
> > >
> > > static void kvm_vcpu_reset_sve(struct kvm_vcpu *vcpu)
> > > --
> > > 2.33.0
> > >
^ permalink raw reply
* Re: [PATCH v9 2/9] lib: vsprintf: export simple_strntoull() in a safe prototype
From: Rodrigo Alencar @ 2026-03-27 15:17 UTC (permalink / raw)
To: Andy Shevchenko, Rodrigo Alencar
Cc: Petr Mladek, rodrigo.alencar, linux-kernel, linux-iio, devicetree,
linux-doc, Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Steven Rostedt, Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <acZaGUV0MwuHNDru@ashevche-desk.local>
On 26/03/27 12:21PM, Andy Shevchenko wrote:
> On Fri, Mar 27, 2026 at 10:11:56AM +0000, Rodrigo Alencar wrote:
> > On 26/03/27 11:17AM, Andy Shevchenko wrote:
> > > On Fri, Mar 27, 2026 at 09:45:17AM +0100, Petr Mladek wrote:
> > > > On Fri 2026-03-20 16:27:27, Rodrigo Alencar via B4 Relay wrote:
>
> ...
>
> > > > > +extern ssize_t __must_check simple_strntoull(const char *startp, const char **endp,
> > > > > + unsigned int base, size_t max_chars,
> > > > > + unsigned long long *res);
> > > >
> > > > Sigh, naming is hard. I personally find it a bit confusing that the
> > > > name is too similar to the unsafe API.
> > > >
> > > > IMHO, the semantic of the new API is closer to kstrtoull().
> > > > It just limits the size, so I would call it kstrntoull().
> > >
> > > It's not. kstrto*() quite strict about the input, this one is actually relaxed
> > > variant, so I wouldn't mix these two groups.
> > >
> > > > Also I would use int as the return parameter, see below.
>
> ...
>
> > > TBH, I am skeptical about this approach. My main objection is max_chars
> > > parameter. If we want to limit the input strictly to the given number of
> > > characters, we have to copy the string and then just use kstrto*() in a normal
> > > way. The whole idea of that parameter is to be able to parse the fractional
> > > part of the float number as 'iiiii.fffff', where 'i' is for integer part, and
> > > 'f' for the fractional. Since we have *endp, we may simply check that.
> >
> > A max_chars would not be only useful for that. It can prevent out-of-bounds
> > reads when the input isn't NUL-terminated (like buffers, file chunks,
> > network packets, memory-mapped data, ....). Even if there is a NUL later in
> > memory, a regular strtoull() function may consume characters that are outside
> > the field one intends to parse.
>
> Okay, but is it the current case or just an attempt to solve the problem that
> doesn't exist (yet)?
The current case can be seen as such. Copying the string and use regular ksrto*()
requires an unecessary scan of string from the user side, which is something that
_parse_integer_limit() already does, mostly because it checks for digits and stops
at any non-digit character. In the IIO case, we also want control over the consumed
characters because there are weird terminations like "dB", so having an implementation
like this ends up with a cleaner sequence of steps.
> > > In case if we want to parse only, say, 6 digits and input is longer there are
> > > a few options (in my personal preferences, the first is the better):
> > > - consider the input invalid
> > > - parse it as is up to the maximum and then do ceil() or floor() on top of that
> > > - copy only necessary amount of the (sub)string and parse that.
> >
> > Yes, my use case is the fixed point parsing, but I suppose we are implementing
> > things here for reuse.
>
> Yes, I'm full for reuse, but I want to have it balanced between complexity,
> existing use cases and possible reuse in the future.
Not seeing complexity here as in this case I am just exposing something
that already exists! No need for a completely different implementation.
I just want to get an agreement on the naming and interface prototype.
Bringing back the discussion again just because I suppose Petr havent even
seen the v8 of this patch series. If kstrtox.h is the right place for this,
kstrntoull() sounds like ideal. Specially because simple_strto*() is already
labeled as unsafe and kstrnto*() != kstrto*().
> > Also, the default behavior of the previous fixed point
> > parsing in IIO is flooring the result, which leads to the same result as
> > ignoring further digits.
>
> Correct, I also lean to implying floor() (as you can read below).
>
> > > The problem with precision is that we need to also consider floor() or ceil()
> > > and I don't think this should be burden of the library as it's individual
> > > preference of each of the callers (users). At least for the starter, we will
> > > see if it's only one approach is used, we may incorporate it into the library
> > > code.
> > >
> > > The easiest way out is to just consider the input invalid if it overflows the
> > > given type (s32 or s64).
> > >
> > > But we need to have an agreement what will be the representation of the
> > > fixed-width float numbers in the kernel? Currently IIO uses
> > > struct float // name is crafted for simplicity
> > > {
> > > int integer;
> > > int fraction;
> > > }
> >
> > Yes, but to represent things like that, an assumption is made to the precision that
> > "fraction" carries.
>
> Correct.
>
> > > This parser wants AFAIU to have at the end of the day something like
> > >
> > > struct float
> > > {
> > > s64 integer;
> > > s64 fraction;
> > > }
> > >
> > > but also wants to have the fraction part be limited in some cases to s32
> > > or so:
> > >
> > > struct float
> > > {
> > > s64 integer;
> > > s32 fraction; // precision may be lost if input is longer
> > > }
> > >
> > > Maybe we want to have kstrtof32() and kstrtof64() for these two cases?
> > >
> > > With that we will always consider the fraction part as 32- or 64-bit,
> > > imply floor() on the fraction for the sake of simplicity and require
> > > it to be NUL-terminated with possible trailing '\n'.
> >
> > I think this is a good idea, but calling it float or fixed point itself
> > is a bit confusing as float often refers to the IEEE 754 standard and
> > fixed point types is often expressed in Q-format.
>
> Yeah... I am lack of better naming.
decimals is the name, but they are often represented as:
DECIMAL = INT * 10^X + FRAC
in a single 64-bit number, which would be fine for my end use case.
However IIO decimal fixed point parsing is out there for quite some time a
lot of drivers use that. The interface often relies on breaking parsed values
into an integer array (for standard attributes int val and int val2 are expected).
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH 0/4] hwmon: Add WITRN USB tester driver
From: Guenter Roeck @ 2026-03-27 15:42 UTC (permalink / raw)
To: Rong Zhang, Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, linux-kernel, linux-doc
In-Reply-To: <5ee967a8a4dca6f70e50c7fac382d4f91b6620aa.camel@rong.moe>
On 3/27/26 05:01, Rong Zhang wrote:
> Hi Guenter,
>
> Thanks a lot for your review and applying patch 1 :-)
>
> On Thu, 2026-03-26 at 17:05 -0700, Guenter Roeck wrote:
>> On 3/26/26 12:19, Rong Zhang wrote:
>>> WITRN produces a series of devices to monitor power characteristics of
>>> USB connections and display those on a on-device display. Most of them
>>> contain an additional port which exposes the measurements via USB HID.
>>>
>>> These devices report sensor values in IEEE-754 float (binary32) format.
>>> The driver must perform floating-point number to integer conversions to
>>> provide hwmon channels. Meanwhile, they also report accumulative float
>>> values, and simple division or multiplication turns them into useful
>>> hwmon channels.
>>>
>>> Patch 1 adds label support for 64-bit energy attributes, as the driver
>>> needs it.
>>>
>>> Patch 2 adds a helper module for floating-point to integer conversions,
>>> so that the conversion, multification and division methods can be used
>>> in this driver as well as other drivers (I am also working on another
>>> USB tester driver that needs it).
>>>
>>> Patch 3 adds a barebone HID driver for WITRN K2.
>>>
>>> Patch 4 adds hwmon channels and attributes to the driver.
>>>
>>> Signed-off-by: Rong Zhang <i@rong.moe>
>>> ---
>>> Rong Zhang (4):
>>> hwmon: Add label support for 64-bit energy attributes
>>> hwmon: New helper module for floating-point to integer conversions
>>
>> Nack. This is not a hwmon problem and should reside in a driver or in lib/
>> (if it is needed by multiple drivers).
>
> Makes sense. I will try.
>
>>
>>> hwmon: Add barebone HID driver for WITRN
>>
>> Nack. This is the wrong place for such a driver. It should reside somewhere
>> in drivers/usb, or maybe in drivers/misc/.
>
> Hmm, I decided to place it here because:
>
> - It's not a hid_ll_driver but a dumb hid_driver, i.e., does no low
> level things but just receives hid event from the HID core. It doesn't
> even send any HID report to the device.
>
> - There has been numerous hid_driver in drivers/hwmon/.
>
> - There has been a similar USB tester driver in drivers/hwmon/, i.e.,
> powerz. That's the major reason of my decision.
>
powerz is a pure hwmon driver, nothing else. It does not claim to be a
"pure hid driver". If your driver _only_ provides a hwmon ABI, it would
be acceptable. But then this and the next patch should be one patch,
and it should only provide the hwmon ABI, nothing else (except maybe
debugfs entries or sysfs entries attached directly to the HID device
to display information such as serial number etc). Reading ROM/RAM addresses,
as mentioned below, would be outside that scope.
The entire powerz driver is 269 lines of code. Your driver has well above
1,000 LOC. Your code has separate source files plus an include file.
That suggests that it does more than just reporting hardware monitoring
attributes.
I have not looked further into the code itself. My response is based purely
on the subjects and code organization, which suggests that this is a HID
driver with attached hardware monitoring.
I am not sure I understand what all that would have to do with UCSI. UCSI
support is implemented in drivers/usb/typec/ucsi. Anything associated
with that protocol should be implemented there if it is part of the
protocol.
> Could you kindly explain what kinds of driver can be accepted into
> drivers/hwmon/?
>
>>
>>> hwmon: (witrn) Add monitoring support
>>
>> This should be implemented as auxiliary driver.
>
> Could you kindly elaborate? Did you mean that if the device supports
> multiple functionalities they should be implemented as multiple
> auxiliary drivers in different subsystems?
>
Correct. Your series suggests that this would be the case.
> FYI, the USB tester doesn't provide any other meaningful feature that
> fits other subsystems. The tester only provides two features through USB
> HID: power measurements (this series), and raw PD packets sniffing.
>
Again, support for raw PD packets sniffing would be outside the scope
of the hardware monitoring subsystem.
Thanks,
Guenter
> As for the latter, the USB tester can sniff raw PD packets between the
> source and sink if enabled in the device menu. It doesn't provide the
> parsed result for packets, and the PC cannot ask the tester to send PD
> packets. This doesn't fit UCSI at all, as a UCSI device operates at a
> higher level and must accept commands. AFAIK such a dumb sniffer won't
> fit any subsystem in the kernel. Hence, the only thing fits a subsystem
> is its power measurements.
>
> All measurements supported by the official utility for Windows can be
> found in `struct witrn_sensor'. Other than that, all extra features
> provided by the utility are implemented in software and I didn't see any
> extra USB packets other than querying the serial number [1] when I was
> randomly messing around with the utility [2].
>
> I separated patch 3 and 4 just for easier review. If you are not in
> favor of such a style, I will squash them.
>
> [1]: In fact, the utility directly asks the device to return the content
> on several specific ROM/RAM addresses, and then the utility calculates
> the serial number with an unknown algorithm. Reading a ROM/RAM address
> seems to be the only command that the device accepts from the USB host.
>
> [2]: Yeah, their utility does not support PD packet capturing or
> parsing. It seems that the manufacturer provides the PD sniffing feature
> as is and expects users to capture it via hidraw or libusb and parse it
> themselves.
>
>>
>> Sashiko has a lot of feedback that you might want to address before
>> resubmitting.
>>
>> https://sashiko.dev/#/patchset/20260327-b4-hwmon-witrn-v1-0-8d2f1896c045%40rong.moe
>
> Sashiko's feedback helps a lot. Thanks.
>
> Thanks,
> Rong
>
>>
>> Thanks,
>> Guenter
>>
>>>
>>> Documentation/hwmon/index.rst | 1 +
>>> Documentation/hwmon/witrn.rst | 53 ++++
>>> MAINTAINERS | 7 +
>>> drivers/hwmon/Kconfig | 14 +
>>> drivers/hwmon/Makefile | 2 +
>>> drivers/hwmon/hwmon-fp.c | 262 ++++++++++++++++
>>> drivers/hwmon/hwmon-fp.h | 212 +++++++++++++
>>> drivers/hwmon/hwmon.c | 1 +
>>> drivers/hwmon/witrn.c | 691 ++++++++++++++++++++++++++++++++++++++++++
>>> 9 files changed, 1243 insertions(+)
>>> ---
>>> base-commit: 0138af2472dfdef0d56fc4697416eaa0ff2589bd
>>> change-id: 20260327-b4-hwmon-witrn-a629b9040250
>>>
>>> Thanks,
>>> Rong
>>>
^ permalink raw reply
* Re: [PATCH v6 01/40] arm_mpam: Ensure in_reset_state is false after applying configuration
From: James Morse @ 2026-03-27 15:42 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, jonathan.cameron, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, reinette.chatre, rohit.mathew, scott, sdonthineni,
tan.shaopeng, xhao, catalin.marinas, will, corbet, maz, oupton,
joey.gouly, suzuki.poulose, kvmarm, zengheng4, linux-doc
In-Reply-To: <20260313144617.3420416-2-ben.horgan@arm.com>
Hi Ben, Zeng,
On 13/03/2026 14:45, Ben Horgan wrote:
> From: Zeng Heng <zengheng4@huawei.com>
>
> The per-RIS flag, in_reset_state, indicates whether or not the MSC
> registers are in reset state, and allows avoiding resetting when they are
> already in reset state. However, when mpam_apply_config() updates the
> configuration it doesn't update the in_reset_state flag and so even after
> the configuration update in_reset_state can be true and mpam_reset_ris()
> will skip the actual register restoration on subsequent resets.
>
> Once resctrl has a MPAM backend it will use resctrl_arch_reset_all_ctrls()
> to reset the MSC configuration on unmount and, if the in_reset_state flag
> is bogusly true, fail to reset the MSC configuration. The resulting
> non-reset MSC configuration can lead to persistent performance restrictions
> even after resctrl is unmounted.
>
> Fix by clearing in_reset_state to false immediately after successful
> configuration application, ensuring that the next reset operation
> properly restores MSC register defaults.
Reviewed-by: James Morse <james.morse@arm.com>
Thanks!
James
^ permalink raw reply
* Re: [PATCH v6 08/40] arm64: mpam: Drop the CONFIG_EXPERT restriction
From: James Morse @ 2026-03-27 15:43 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, jonathan.cameron, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, reinette.chatre, rohit.mathew, scott, sdonthineni,
tan.shaopeng, xhao, catalin.marinas, will, corbet, maz, oupton,
joey.gouly, suzuki.poulose, kvmarm, zengheng4, linux-doc,
Shaopeng Tan
In-Reply-To: <20260313144617.3420416-9-ben.horgan@arm.com>
Hi Ben,
On 13/03/2026 14:45, Ben Horgan wrote:
> In anticipation of MPAM being useful remove the CONFIG_EXPERT restriction.
Useful - ha! I've added a second paragraph describing why this was done, just
so it doesn't look odd in 5 years time.
| This was done to prevent the driver being enabled before the user-space
| interface was wired up.
Reviewed-by: James Morse <james.morse@arm.com>
Thanks,
James
^ permalink raw reply
* Re: [PATCH v6 11/40] arm64: mpam: Initialise and context switch the MPAMSM_EL1 register
From: James Morse @ 2026-03-27 15:44 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, jonathan.cameron, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, reinette.chatre, rohit.mathew, scott, sdonthineni,
tan.shaopeng, xhao, catalin.marinas, will, corbet, maz, oupton,
joey.gouly, suzuki.poulose, kvmarm, zengheng4, linux-doc,
Shaopeng Tan
In-Reply-To: <20260313144617.3420416-12-ben.horgan@arm.com>
Hi Ben,
On 13/03/2026 14:45, Ben Horgan wrote:
> The MPAMSM_EL1 sets the MPAM labels, PMG and PARTID, for loads and stores
> generated by a shared SMCU. Disable the traps so the kernel can use it and
> set it to the same configuration as the per-EL cpu MPAM configuration.
>
> If an SMCU is not shared with other cpus then it is implementation
> defined whether the configuration from MPAMSM_EL1 is used or that from
> the appropriate MPAMy_ELx. As we set the same, PMG_D and PARTID_D,
> configuration for MPAM0_EL1, MPAM1_EL1 and MPAMSM_EL1 the resulting
> configuration is the same regardless.
>
> The range of valid configurations for the PARTID and PMG in MPAMSM_EL1 is
> not currently specified in Arm Architectural Reference Manual but the
> architect has confirmed that it is intended to be the same as that for the
> cpu configuration in the MPAMy_ELx registers.
Reviewed-by: James Morse <james.morse@arm.com>
> diff --git a/arch/arm64/include/asm/mpam.h b/arch/arm64/include/asm/mpam.h
> index 0747e0526927..6bccbfdccb87 100644
> --- a/arch/arm64/include/asm/mpam.h
> +++ b/arch/arm64/include/asm/mpam.h
> @@ -53,6 +53,8 @@ static inline void mpam_thread_switch(struct task_struct *tsk)
> return;
>
> write_sysreg_s(regval | MPAM1_EL1_MPAMEN, SYS_MPAM1_EL1);
> + if (system_supports_sme())
> + write_sysreg_s(regval & (MPAMSM_EL1_PARTID_D | MPAMSM_EL1_PMG_D), SYS_MPAMSM_EL1);
Doing it here saves a surprise later.
> isb();
> /* Synchronising the EL0 write is left until the ERET to EL0 */
(down here would have been the alternative)
Thanks,
James
^ permalink raw reply
* Re: [PATCH v6 21/40] arm_mpam: resctrl: Hide CDP emulation behind CONFIG_EXPERT
From: James Morse @ 2026-03-27 15:44 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, jonathan.cameron, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, reinette.chatre, rohit.mathew, scott, sdonthineni,
tan.shaopeng, xhao, catalin.marinas, will, corbet, maz, oupton,
joey.gouly, suzuki.poulose, kvmarm, zengheng4, linux-doc
In-Reply-To: <20260313144617.3420416-22-ben.horgan@arm.com>
Hi Ben,
On 13/03/2026 14:45, Ben Horgan wrote:
> When CDP is not enabled, the 'rmid_entry's in the limbo list,
> rmid_busy_llc, map directly to a (PARTID,PMG) pair and when CDP is enabled
> the mapping is to two different pairs.
> As the limbo list is reused between
> mounts and CDP disabled on unmount this can lead to stale mapping and the
> limbo handler will then make monitor reads with potentially out of range
> PARTID.
Bother - I missed that!
> This may then cause an MPAM error interrupt and the driver will
> disable MPAM.
... and that's why it's not a problem on x86 because the RMID range is unaffected by CDP,
whereas MPAM works on a combined value.
> No problems are expected if you just mount the resctrl file system
> once with CDP enabled and never unmount it.
(guess how it was tested!)
> Hide CDP emulation behind CONFIG_EXPERT to protect the unwary.
>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Adding this ugliness in the hope of avoiding patch churn and extra
> reviewer work. I am looking into the resctrl changes needed to fix this.
Makes sense - people can still use this if they're aware of the limitation, and it sounds
like you've got a plan to fix it properly. We just don't want it enabled in distros until
then.
> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
> index 903d1a0f564f..cab3e9ccb5c7 100644
> --- a/drivers/resctrl/mpam_resctrl.c
> +++ b/drivers/resctrl/mpam_resctrl.c
> @@ -82,6 +82,18 @@ int resctrl_arch_set_cdp_enabled(enum resctrl_res_level rid, bool enable)
> u32 partid_i = RESCTRL_RESERVED_CLOSID, partid_d = RESCTRL_RESERVED_CLOSID;
> int cpu;
>
> + if (!IS_ENABLED(CONFIG_EXPERT) && enable) {
> + /*
> + * If the resctrl fs is mounted more than once, sequentially,
> + * then CDP can lead to the use of out of range PARTIDs.
> + */
> + pr_warn("CDP not supported\n");
> + return -EOPNOTSUPP;
> + }
> +
> + if (enable)
> + pr_warn("CDP is an expert feature and may cause MPAM to malfunction.\n");
> +
> /*
> * resctrl_arch_set_cdp_enabled() is only called with enable set to
> * false on error and unmount.
Reviewed-by: James Morse <james.morse@arm.com>
Thanks,
James
^ permalink raw reply
* Re: [PATCH v6 22/40] arm_mpam: resctrl: Convert to/from MPAMs fixed-point formats
From: James Morse @ 2026-03-27 15:47 UTC (permalink / raw)
To: Gavin Shan, Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, jonathan.cameron, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, reinette.chatre, rohit.mathew, scott, sdonthineni,
tan.shaopeng, xhao, catalin.marinas, will, corbet, maz, oupton,
joey.gouly, suzuki.poulose, kvmarm, zengheng4, linux-doc,
Shaopeng Tan
In-Reply-To: <bd450f1f-05a3-44d6-9bbc-1c48d967baa4@redhat.com>
Hi Gavin,
On 23/03/2026 22:49, Gavin Shan wrote:
> On 3/14/26 12:45 AM, Ben Horgan wrote:
>> From: Dave Martin <Dave.Martin@arm.com>
>>
>> MPAM uses a fixed-point formats for some hardware controls. Resctrl
>> provides the bandwidth controls as a percentage. Add helpers to convert
>> between these.
>>
>> Ensure bwa_wd is at most 16 to make it clear higher values have no meaning.
> One nitpick below, but this looks good to me in either way.
>
> Reviewed-by: Gavin Shan <gshan@redhat.com>
Thanks!
>> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
>> index 0e5e24ef60fe..0c97f7708722 100644
>> --- a/drivers/resctrl/mpam_devices.c
>> +++ b/drivers/resctrl/mpam_devices.c
>> @@ -713,6 +713,13 @@ static void mpam_ris_hw_probe(struct mpam_msc_ris *ris)
>> mpam_set_feature(mpam_feat_mbw_part, props);
>> props->bwa_wd = FIELD_GET(MPAMF_MBW_IDR_BWA_WD, mbw_features);
>> +
>> + /*
>> + * The BWA_WD field can represent 0-63, but the control fields it
>> + * describes have a maximum of 16 bits.
>> + */
>> + props->bwa_wd = min(props->bwa_wd, 16);
>> +
>
> 16 may deserve a definition for it since it's a constant value and referred
> for multiple times in this patch, if we need to give this series another
> respin :-)
Hmmm.,. I've left this, I'm not sure what you'd call it. U16_BITS? That sort of thing
might be needed for long/int etc. Here there is either a comment, or its
accepting/returning a u16. I think its fairly obvious where the number 16 is coming from.
Thanks,
James
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox