Os engenheiros do Google e outras partes estão interessados ??em poder criar espaços de troca em distribuições Linux que seriam reservados apenas para fins de suspensão e hibernação do sistema e não para troca genérica para o disco. Portanto, o Google trabalha na criação de espaços de hibernação para distribuições Linux.
O SWAP_FLAG_HIBERNATE_ONLY proposto reservaria um espaço de troca apenas para o uso de suspensão para o disco e não para troca de páginas regulares. Até agora, a troca genérica precisa ser ativada se quiser apenas usá-la para suspender o sistema, sem soluções alternativas para ativá-la ou desativá-la durante o processo de suspensão.
Google trabalha em criação de espaços de hibernação para distribuições Linux
Entre os motivos para suspender apenas espaços de troca:
Existem algumas razões pelas quais o modo do usuário pode querer ser capaz de controlar exclusivamente a troca e a hibernação. Um dos motivos está relacionado ao uso de SSD. Os requisitos de resistência e velocidade do Hibernate são diferentes da troca. Pode ser vantajoso, por exemplo, manter a hibernação no armazenamento primário, mas colocar a troca em um namespace SLC. Esses namespaces são mais rápidos e têm melhor durabilidade, mas custam 3-4x em termos de capacidade.
O controle exclusivo de hibernação e troca permite que os projetistas de sistema particionem com precisão seu armazenamento sem gastar o armazenamento primário ou superprovisionar sua área de troca rápida.Outra razão para permitir uma direção exclusiva tem a ver com a segurança. Os requisitos para projetar sistemas com resiliência contra ataques offline são diferentes entre troca e hibernação. A troca requer efetivamente um dicionário de hashes, já que as páginas podem ser adicionadas e removidas arbitrariamente, enquanto o hibernate só precisa de um único hash para a imagem inteira. Se você configurou a integridade de nível de bloco para troca e integridade de nível de imagem para hibernação, então permitir que os blocos de troca vazem para a região de hibernação é problemático, pois cria páginas de troca não protegidas por nenhuma integridade.
Recentemente, foi enviado o mais recente patch implementando este sinalizador somente hibernação para swap. Esta revisão altera o nome do sinalizador e tem várias outras melhorias de código para esta funcionalidade proposta.
Desenvolvedores de RISC-V continuam trabalhando no suporte KVM
O esforço para suportar a virtualização KVM com a arquitetura RISC-V já dura mais de um ano. Isso é muito importante para que os processadores RISC-V possam, eventualmente, aumentar o espaço do servidor. O trabalho de ativação do KVM RISC-V está agora em sua décima nona revisão, mas ainda não está claro se ele está pronto para a integração.
Este suporte KVM RISC-V foi liderado pela Western Digital, que permanece muito ativo com vários elementos de suporte RISC-V Linux. Com esta longa série de patches de trabalho em andamento, eles podem inicializar convidados RISC-V de 32 e 64 bits com várias CPUs virtuais em hardware RISC-V. Ainda a ser abordado no futuro, porém, é lidar com a emulação SBI (Supervisor Binary Interface) v0.2 dentro do kernel, entre outros SBI v0.2 bits, bem como emulação PLIC no kernel e outros recursos. A Western Digital também está trabalhando em um kvmtool portado para RISC-V para demonstrar o suporte RISC-V KVM e fazer uso dele, enquanto o mestre QEMU Git também suporta RISC-V.
Com esta 19ª rodada dos patches KVM RISC-V, o código foi refeito no estado upstream do Linux mais recente, agora aproveita uma nova interface KVM DebugFS e descarta a ideia de inicialmente ter KVM RISC-V dentro da área de teste de drivers .
Veja esta série de patch para aqueles interessados ??no futuro suporte KVM RISC-V.