From nobody Thu Dec 18 07:09:44 2025 Received: from mail-oa1-f54.google.com (mail-oa1-f54.google.com [209.85.160.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6D55C53364; Wed, 26 Jun 2024 22:19:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719440387; cv=none; b=QuMeYs0mabI5XlOlepfR2/RxaDnVnDDDZgLTjZLT22pKRE1pHkFAPNRd1293fkH9zawE84aKTS0ChV7zhdpr27julO2t0oJ/D7ebCAlAJWLO87UtFBeGZbmi5mL1YBUdtlrvNWiKCtabIErn24nhz4JJcQsVsNQZYcXgXGF2GZY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719440387; c=relaxed/simple; bh=1gmWog+2IL9Fk2fhZKz0wdtqR5GqpMRdY5PEvj50O2U=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=lPwtYlo5ZhYmqR+lYFTubvJ4mWRsgvBFQK/YJ1zjz7eycuuS/z+pHULBXqBKjs1Dwhh3yOoEqOVVGz1I5d4dDYiQRfyPJPxWevCgOzYwC0fqHN2q9/ZjLaXpdKPZGbqP2WlamxfUitvhc+1vNb9jycqK23f17d8dCqOWL6Xly4k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=YmS6YQPj; arc=none smtp.client-ip=209.85.160.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YmS6YQPj" Received: by mail-oa1-f54.google.com with SMTP id 586e51a60fabf-25c9786835eso3738842fac.3; Wed, 26 Jun 2024 15:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719440384; x=1720045184; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=HVI3Q2He2eesxNtx4DcO7QmeODYRI57Ul7OmvDlSY5Y=; b=YmS6YQPjXP1xi8aMETaKP2QHiiET3FhnG7Ll3CnyP3+RICJLg4L6pcJsyOgOcXYR4G XvJY3jze1gdAf6uA0sws6F+CncsGz8vSUr4VwOj9fn1mt+yVdIZoWWNfsHRkhxJJebQ/ KeDDrThgJZW3wZz2peKffmMtmEcTf5XdgLgQBCdxq8MDowDWJ697imAS8aX4KTzP0KM7 jMKiIoFx2aq0ejqqPBfkR4szgBq8r+Cc1xpLLjH6meFFMYL7aJ0FCiurQIdj91jMrM44 ek4IYkEaROpyzHRsg00KaziYmmtD7hcaSDCi8/BXAzt+kysrA/oNaIYjxiDg18T299UK OrxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719440384; x=1720045184; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HVI3Q2He2eesxNtx4DcO7QmeODYRI57Ul7OmvDlSY5Y=; b=r+qlMZr9mK80MZmJL2cZzb5t0RPEBs+v5G9cjdMG4w96CMmJ1nqwoVLJeFij3uFzAM dfxDb1d1If8ShMO+4cxC/biYCXSiN9HV+QB1I8AX3slg8pP8E/bHtSf6soDbE58L04vx LRggI8iWbf4gqiUa0wE5TXOmm4DOi2KiEKjAoUIyJrFHh1i0KNTsVZmI2LoW329VmFnO 9oVP0R+pn3vFxZUvV5X1zNpA4JCoz30PWbNHqN7glonvhMx0nVGzNvGRYOpVUB06GVN1 vs+36o8ukn4eSUY3/9OBxzna2Blf2N001sq/gMpwLEiZ7npcO9PIA+Kja7uxRPuqsHyP TvfQ== X-Forwarded-Encrypted: i=1; AJvYcCWT3DsOJs3dlOwG5AMFQVmt4krgycw9d8/LjYskNbcdAYtYdw1Tb2s+iUA7C2aSwpBSVoVGUTvSQdM/dz3w4BdmDP7YZuAuKHtNvo6AiKT4KHZelWAh5FZIMtI++hYfV+T4L85Hc0ot X-Gm-Message-State: AOJu0YyBv6eC00SdoFCK6UaPLsohCqMe5m7ZC3Um8aumy2GC7PimFZyp ykerlSFxBWhjZ6ajAitp2Jf7n1/bSMtbHzHAnq+IyjGLKrCXQs/P X-Google-Smtp-Source: AGHT+IFCIi9OiSt+DlDrWiJL7Vycg+vilAcpvmkr+jbNROVzq3j+PZy46T6snXkbhUb8e49fcfAYqA== X-Received: by 2002:a05:6870:a2c7:b0:250:8913:7400 with SMTP id 586e51a60fabf-25d06e37922mr12374760fac.40.1719440384039; Wed, 26 Jun 2024 15:19:44 -0700 (PDT) Received: from pipaware.austin.rr.com ([2603:8080:2300:de:3d70:f8:6869:93de]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-25d72af181bsm41076fac.6.2024.06.26.15.19.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Jun 2024 15:19:43 -0700 (PDT) From: Carlos Bilbao To: corbet@lwn.net Cc: bilbao@vt.edu, jembid@ucm.es, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Carlos Bilbao Subject: [PATCH] docs/sp_SP: Add translation of process/maintainer-kvm-x86.rst Date: Wed, 26 Jun 2024 17:19:41 -0500 Message-ID: <20240626221942.2780668-1-carlos.bilbao.osdev@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Translate Documentation/process/maintainer-kvm-x86.rst into Spanish. Co-developed-by: Juan Embid Signed-off-by: Juan Embid Signed-off-by: Carlos Bilbao --- .../translations/sp_SP/process/index.rst | 1 + .../sp_SP/process/maintainer-kvm-x86.rst | 466 ++++++++++++++++++ 2 files changed, 467 insertions(+) create mode 100644 Documentation/translations/sp_SP/process/maintainer-kvm= -x86.rst diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documenta= tion/translations/sp_SP/process/index.rst index 4892159310ff..adb2cc845928 100644 --- a/Documentation/translations/sp_SP/process/index.rst +++ b/Documentation/translations/sp_SP/process/index.rst @@ -29,3 +29,4 @@ submit-checklist howto development-process + maintainer-kvm-x86 diff --git a/Documentation/translations/sp_SP/process/maintainer-kvm-x86.rs= t b/Documentation/translations/sp_SP/process/maintainer-kvm-x86.rst new file mode 100644 index 000000000000..127238f44ea9 --- /dev/null +++ b/Documentation/translations/sp_SP/process/maintainer-kvm-x86.rst @@ -0,0 +1,466 @@ +.. include:: ../disclaimer-sp.rst + +:Original: :ref:`Documentation/process/maintainer-kvm-x86.rst` +:Translator: Juan Embid + +KVM x86 +=3D=3D=3D=3D=3D=3D=3D + +Pr=C3=B3logo +-------- +KVM se esfuerza por ser una comunidad acogedora; las contribuciones de los +reci=C3=A9n llegados son valoradas e incentivadas. Por favor, no se desani= me ni +se sienta intimidado por la extensi=C3=B3n de este documento y las numeros= as +normas/directrices que contiene. Todos cometemos errores y todos hemos sido +principiantes en alg=C3=BAn momento. Mientras haga un esfuerzo honesto por +seguir las directrices de KVM x86, sea receptivo a los comentarios, y +aprenda de los errores que cometa, ser=C3=A1 recibido con los brazos abier= tos, +no con antorchas y horcas. + +TL;DR +----- +Las pruebas son obligatorias. Sea coherente con los estilos y patrones +establecidos. + +=C3=81rboles +------- +KVM x86 se encuentra actualmente en un per=C3=ADodo de transici=C3=B3n de = ser parte +del =C3=A1rbol principal de KVM, a ser "s=C3=B3lo otra rama de KVM". Como = tal, KVM +x86 est=C3=A1 dividido entre el =C3=A1rbol principal de KVM, +``git.kernel.org/pub/scm/virt/kvm/kvm.git``, y un =C3=A1rbol espec=C3=ADfi= co de KVM +x86, ``github.com/kvm-x86/linux.git``. + +Por lo general, las correcciones para el ciclo en curso se aplican +directamente al =C3=A1rbol principal de KVM, mientras que todo el desarrol= lo +para el siguiente ciclo se dirige a trav=C3=A9s del =C3=A1rbol de KVM x86.= En el +improbable caso de que una correcci=C3=B3n para el ciclo actual se dirija a +trav=C3=A9s del =C3=A1rbol KVM x86, se aplicar=C3=A1 a la rama ``fixes`` a= ntes de llegar +al =C3=A1rbol KVM principal. + +Tenga en cuenta que se espera que este periodo de transici=C3=B3n dure bas= tante +tiempo, es decir, que ser=C3=A1 el statu quo en un futuro previsible. + +Ramas +~~~~~ +El =C3=A1rbol de KVM x86 est=C3=A1 organizado en m=C3=BAltiples ramas por = temas. El +prop=C3=B3sito de utilizar ramas tem=C3=A1ticas m=C3=A1s espec=C3=ADficas = es facilitar el +control de un =C3=A1rea de desarrollo, y para limitar los da=C3=B1os colat= erales de +errores humanos y/o commits con errores, por ejemplo, borrar el commit HEAD +de una rama tem=C3=A1tica no tiene impacto en los hashes SHA1 de otros com= mit +en en camino, y tener que rechazar una solicitud de pull debido a errores +retrasa s=C3=B3lo esa rama tem=C3=A1tica. + +Todas las ramas tem=C3=A1ticas, excepto ``next`` y ``fixes``, se agrupan en +``next`` a trav=C3=A9s de un Cthulhu merge en funci=C3=B3n de las necesida= des, es +decir, cuando se actualiza una rama tem=C3=A1tica. Como resultado, los push +forzados a ``next`` son comunes. + +Ciclo de Vida +~~~~~~~~~~~~~ +Las correcciones dirigidas a la versi=C3=B3n actual, tambi=C3=A9n conocida= como +mainline, suelen aplicarse directamente al =C3=A1rbol principal de KVM, es +decir, no pasan por el =C3=A1rbol x86 de KVM. + +Los cambios dirigidos a la siguiente versi=C3=B3n se dirigen a trav=C3=A9s= del =C3=A1rbol +KVM x86. Se env=C3=ADan pull requests (de KVM x86 a KVM main) para cada ra= ma +tem=C3=A1tica de KVM x86, normalmente la semana antes de que Linus abra la +ventana de fusi=C3=B3n, por ejemplo, la semana siguiente a rc7 para las +versiones "normales". Si todo va bien, las ramas tem=C3=A1ticas son subida= s en +el pull request principal de KVM enviado durante la ventana de fusi=C3=B3n= de +Linus. + +El =C3=A1rbol de KVM x86 no tiene su propia ventana de fusi=C3=B3n oficial= , pero hay +un cierre suave alrededor de rc5 para nuevas caracter=C3=ADsticas, y un ci= erre +suave alrededor de rc6 para correcciones (para la pr=C3=B3xima versi=C3=B3= n; f=C3=ADjese +m=C3=A1s arriba para las correcciones dirigidas a la versi=C3=B3n actual). + +Cronolog=C3=ADa +~~~~~~~~~~ +Normalmente, los env=C3=ADos se revisan y aplican en orden FIFO, con cierto +margen de maniobra en funci=C3=B3n del tama=C3=B1o de la serie, los parche= s que est=C3=A1n +"calientes en cach=C3=A9", etc. Correcciones, especialmente para la versi= =C3=B3n +actual y/o =C3=A1rboles estables, consiguen saltar la cola. Los parches qu= e se +lleven a trav=C3=A9s de un =C3=A1rbol que no sea KVM (la mayor=C3=ADa de l= as veces a +trav=C3=A9s del =C3=A1rbol de consejos) y/o que tengan otros acks/revision= es tambi=C3=A9n +saltan la cola hasta cierto punto. + +Tenga en cuenta que la mayor parte de la revisi=C3=B3n se realiza entre rc= 1 y +rc6, m=C3=A1s o menos. El periodo entre la rc6 y la siguiente rc1 se utili= za +para ponerse al d=C3=ADa en otras tareas, es decir, la falta de env=C3=ADo= s durante +este periodo no es inusual. + +Los pings para obtener una actualizaci=C3=B3n del estado son bienvenidos, = pero +tenga en cuenta el calendario del ciclo de publicaci=C3=B3n actual y tenga +expectativas realistas. Si est=C3=A1 haciendo ping para la aceptaci=C3=B3n= , es decir, +no s=C3=B3lo para obtener comentarios o una actualizaci=C3=B3n, por favor = haga todo +lo posible, dentro de lo razonable, para asegurarse de que sus parches +est=C3=A1n listos para ser fusionados. Los pings sobre series que rompen la +compilaci=C3=B3n o fallan en las pruebas provocan el descontento de los +mantenedores. + +Desarrollo +----------- + +=C3=81rbol base/Rama +~~~~~~~~~~~~~~~ +Las correcciones dirigidas a la versi=C3=B3n actual, tambi=C3=A9n conocida= como +mainline, deben basarse en +``git://git.kernel.org/pub/scm/virt/kvm/kvm.git master``. Tenga en cuenta +que las correcciones no garantizan autom=C3=A1ticamente la inclusi=C3=B3n = en la +versi=C3=B3n actual. No hay una regla =C3=BAnica, pero normalmente s=C3=B3= lo las +correcciones de errores urgentes, cr=C3=ADticos y/o introducidos en la ver= si=C3=B3n +actual deber=C3=ADan incluirse en la versi=C3=B3n actual. + +Todo lo dem=C3=A1s deber=C3=ADa basarse en ``kvm-x86/next``, es decir, no = hay +necesidad de seleccionar una rama tem=C3=A1tica espec=C3=ADfica como base.= Si hay +conflictos y/o dependencias entre ramas, es trabajo del mantenedor +resolverlos. + +La =C3=BAnica excepci=C3=B3n al uso de ``kvm-x86/next`` como base es si un +parche/serie es una serie multi-arquitectura, es decir, tiene +modificaciones no triviales en el c=C3=B3digo com=C3=BAn de KVM y/o tiene = cambios m=C3=A1s +que superficiales en el c=C3=B3digo de otras arquitecturas. Los parches/se= ries +multi-arquitectura deber=C3=ADan basarse en un punto com=C3=BAn y estable = en la +historia de KVM, por ejemplo, la versi=C3=B3n candidata en la que se basa +``kvm-x86 next``. Si no est=C3=A1 seguro de si un parche/serie es realmente +multiarquitectura, sea precavido y tr=C3=A1telo como multiarquitectura, es +decir, utilice una base com=C3=BAn. + +Estilo del codigo +~~~~~~~~~~~~~~~~~~~~~~ +Cuando se trata de estilo, nomenclatura, patrones, etc., la coherencia es +la prioridad n=C3=BAmero uno en KVM x86. Si todo lo dem=C3=A1s falla, haga= coincidir +lo que ya existe. + +Con algunas advertencias que se enumeran a continuaci=C3=B3n, siga las +recomendaciones de los responsables del =C3=A1rbol de consejos +:ref:`maintainer-tip-coding-style`, ya que los parches/series a menudo +tocan tanto archivos x86 KVM como no KVM, es decir, llaman la atenci=C3=B3= n de +los mantenedores de KVM *y* del =C3=A1rbol de consejos. + +El uso del abeto inverso, tambi=C3=A9n conocido como =C3=A1rbol de Navidad= inverso o +=C3=A1rbol XMAS inverso, para las declaraciones de variables no es estrict= amente +necesario, aunque es preferible. + +Excepto para unos pocos apuntes especiales, no utilice comentarios +kernel-doc para las funciones. La gran mayor=C3=ADa de las funciones "p=C3= =BAblicas" +de KVM no son realmente p=C3=BAblicas, ya que est=C3=A1n destinadas =C3=BA= nicamente al +consumo interno de KVM (hay planes para privatizar las cabeceras y +exportaciones de KVM para reforzar esto). + +Comentarios +~~~~~~~~~~~ +Escriba los comentarios en modo imperativo y evite los pronombres. Utilice +los comentarios para ofrecer una visi=C3=B3n general de alto nivel del c= =C3=B3digo +y/o para explicar por qu=C3=A9 el c=C3=B3digo hace lo que hace. No reitere= lo que el +c=C3=B3digo hace literalmente; deje que el c=C3=B3digo hable por s=C3=AD m= ismo. Si el +propio c=C3=B3digo es inescrutable, los comentarios no servir=C3=A1n de na= da. + +Referencias SDM y APM +~~~~~~~~~~~~~~~~~~~~~~ +Gran parte de la base de c=C3=B3digo de KVM est=C3=A1 directamente vincula= da al +comportamiento de la arquitectura definido en El Manual de Desarrollo de +Software (SDM) de Intel y el Manual del Programador de Arquitectura (APM) +de AMD. El uso de "SDM de Intel" y "APM de AMD", o incluso s=C3=B3lo "SDM"= o +"APM", sin contexto adicional es correcto. + +No haga referencia a secciones espec=C3=ADficas, tablas, figuras, etc. por= su +n=C3=BAmero, especialmente en los comentarios. En su lugar, si es necesario +(v=C3=A9ase m=C3=A1s abajo), copie y pegue el fragmento correspondiente y = haga +referencia a las secciones/tablas/figuras por su nombre. Los dise=C3=B1os = del +SDM y el APM cambian constantemente, por lo que los n=C3=BAmeros/etiquetas= no +son estables. + +En general, no haga referencia expl=C3=ADcita ni copie-pegue del SDM o APM= en +los comentarios. Con pocas excepciones, KVM *debe* respetar el +comportamiento de la arquitectura, por lo que est=C3=A1 impl=C3=ADcito que= el +comportamiento de KVM est=C3=A1 emulando el comportamiento de SDM y/o APM.= Tenga +en cuenta que hacer referencia al SDM/APM en los registros de cambios para +justificar el cambio y proporcionar contexto es perfectamente correcto y +recomendable. + +Shortlog +~~~~~~~~ +El formato de prefijo m=C3=A1s recomendable es ``KVM: :``, donde +```` es uno de los siguientes:: + +- x86 +- x86/mmu +- x86/pmu +- x86/xen +- autocomprobaciones +- SVM +- nSVM +- VMX +- nVMX + +**=C2=A1NO use x86/kvm!** ``x86/kvm`` se usa exclusivamente para cambios de +Linux virtualizado por KVM, es decir, para arch/x86/kernel/kvm.c. No use +nombres de archivos o archivos completos como prefijo de asunto/shortlog. + +Tenga en cuenta que esto no coincide con las ramas tem=C3=A1ticas (las ram= as +tem=C3=A1ticas se preocupan mucho m=C3=A1s por los conflictos de c=C3=B3di= go). + +Todos los nombres distinguen entre may=C3=BAsculas y min=C3=BAsculas. ``KV= M: x86:`` +es correcto, ``kvm: vmx:`` no lo es. + +Escriba en may=C3=BAsculas la primera palabra de la descripci=C3=B3n conde= nsada del +parche, pero omita la puntuaci=C3=B3n final. Por ejemplo:: + + KVM: x86: Corregir una desviaci=C3=B3n de puntero nulo en function_xyz() + +no:: + + kvm: x86: corregir una desviaci=C3=B3n de puntero nulo en function_xyz. + +Si un parche afecta a varios temas, recorra el =C3=A1rbol conceptual hasta +encontrar el primer padre com=C3=BAn (que suele ser simplemente ``x86``). = En +caso de duda, ``git log path/to/file`` deber=C3=ADa proporcionar una pista +razonable. + +De vez en cuando surgen nuevos temas, pero le rogamos que inicie un debate +en la lista si desea proponer la introducci=C3=B3n de un nuevo tema, es de= cir, +no se ande con rodeos. + +Consulte :ref:`the_canonical_patch_format` para obtener m=C3=A1s informaci= =C3=B3n, +con una enmienda: no trate el l=C3=ADmite de 70-75 caracteres como un l=C3= =ADmite +absoluto y duro. En su lugar, utilice 75 caracteres como l=C3=ADmite firme= , pero +no duro, y 80 caracteres como l=C3=ADmite duro. Es decir, deje que el regi= stro +corto sobrepase en algunos caracteres el l=C3=ADmite est=C3=A1ndar si tien= e una buena +raz=C3=B3n para hacerlo. + +Registro de cambios +~~~~~~~~~~~~~~~~~~~ +Y lo que es m=C3=A1s importante, escriba los registros de cambios en modo +imperativo y evite los pronombres. + +Consulte :ref:`describe_changes` para obtener m=C3=A1s informaci=C3=B3n, c= on una +recomendaci=C3=B3n: comience con un breve resumen de los cambios reales y +contin=C3=BAe con el contexto y los antecedentes. Nota. Este orden entra en +conflicto directo con el enfoque preferido del =C3=A1rbol de sugerencias. = Por +favor, siga el estilo preferido del =C3=A1rbol de sugerencias cuando env= =C3=ADe +parches. que se dirigen principalmente a c=C3=B3digo arch/x86 que _NO_ es = c=C3=B3digo +KVM. + +KVM x86 prefiere indicar lo que hace un parche antes de entrar en detalles +por varias razones. En primer lugar, el c=C3=B3digo que realmente se est= =C3=A1 +cambiando es posiblemente la informaci=C3=B3n m=C3=A1s importante, por lo = que esa +informaci=C3=B3n debe ser f=C3=A1cil de encontrar. Changelogs que entierra= n el "qu=C3=A9 +est=C3=A1 cambiando realmente" en una sola l=C3=ADnea despu=C3=A9s de 3+ p= =C3=A1rrafos de fondo +hacen muy dif=C3=ADcil encontrar esa informaci=C3=B3n. + +Para la revisi=C3=B3n inicial, se podr=C3=ADa argumentar que "lo que est= =C3=A1 roto" es +m=C3=A1s importante, pero para hojear los registros y la arqueolog=C3=ADa = git, los +detalles escabrosos importan cada vez menos. Por ejemplo, al hacer una +serie de "git blame", los detalles de cada cambio a lo largo del camino son +in=C3=BAtiles, los detalles s=C3=B3lo importan para el culpable. Proporcio= nar el "qu=C3=A9 +ha cambiado" facilita determinar r=C3=A1pidamente si una confirmaci=C3=B3n= puede ser +de inter=C3=A9s o no. + +Otra ventaja de decir primero "qu=C3=A9 cambia" es que casi siempre es pos= ible +decir "qu=C3=A9 cambia" en una sola frase. A la inversa, todo menos los er= rores +m=C3=A1s simples requieren varias frases o p=C3=A1rrafos para describir el= problema. +Si tanto "qu=C3=A9 est=C3=A1 cambiando" como "cu=C3=A1l es el fallo" son m= uy breves, el +orden no importa. Pero si uno es m=C3=A1s corto (casi siempre el "qu=C3=A9= est=C3=A1 +cambiando"), entonces cubrir el m=C3=A1s corto primero es ventajoso porque= es +menos inconveniente para los lectores/revisores que tienen una preferencia +estricta de orden. Por ejemplo, tener que saltarse una frase para llegar al +contexto es menos doloroso que tener que saltarse tres p=C3=A1rrafos para = llegar +a "lo que cambia". + +Arreglos +~~~~~~~~ +Si un cambio corrige un error de KVM/kernel, a=C3=B1ada una etiqueta Fixes: +incluso si el cambio no necesita ser retroportado a kernels estables, e +incluso si el cambio corrige un error en una versi=C3=B3n anterior. + +Por el contrario, si es necesario hacer una correcci=C3=B3n, etiquete +expl=C3=ADcitamente el parche con "Cc: stable@vger.kernel" (aunque no es +necesario que el correo electr=C3=B3nico incluya Cc: stable); KVM x86 opta= por +excluirse del backporting Correcciones: por defecto. Algunos parches +seleccionados autom=C3=A1ticamente se retroportan, pero requieren la aprob= aci=C3=B3n +expl=C3=ADcita de los mantenedores (busque MANUALSEL). + +Referencias a Funciones +~~~~~~~~~~~~~~~~~~~~~~~ +Cuando se mencione una funci=C3=B3n en un comentario, registro de cambios o +registro abreviado (o en cualquier otro lugar), utilice el formato +``nombre_de_la_funci=C3=B3n()``. Los par=C3=A9ntesis proporcionan contexto= y +desambiguan la referencia. + +Pruebas +~~~~~~~ +Como m=C3=ADnimo, *todos* los parches de una serie deben construirse limpi= amente +para KVM_INTEL=3Dm KVM_AMD=3Dm, y KVM_WERROR=3Dy. Construir todas las +combinaciones posibles de Kconfigs no es factible, pero cuantas m=C3=A1s m= ejor. +KVM_SMM, KVM_XEN, PROVE_LOCKING, y X86_64 son particularmente interesantes. + +Tambi=C3=A9n es obligatorio ejecutar las autopruebas y las pruebas unitari= as de +KVM (y, como es obvio, las pruebas deben pasar). La =C3=BAnica excepci=C3= =B3n es para +los cambios que tienen una probabilidad insignificante de afectar al +comportamiento en tiempo de ejecuci=C3=B3n, por ejemplo, parches que s=C3= =B3lo +modificar los comentarios. Siempre que sea posible y pertinente, se +recomienda encarecidamente realizar pruebas tanto en Intel como en AMD. Se +recomienda arrancar una m=C3=A1quina virtual real, pero no es obligatorio. + +Para cambios que afecten al c=C3=B3digo de paginaci=C3=B3n en la sombra de= KVM, es +obligatorio ejecutar con TDP (EPT/NPT) deshabilitado. Para cambios que +afecten al c=C3=B3digo MMU com=C3=BAn de KVM, se recomienda encarecidament= e ejecutar +con TDP deshabilitado. Para todos los dem=C3=A1s cambios, si el c=C3=B3dig= o que se +est=C3=A1 modificando depende de y/o interact=C3=BAa con un par=C3=A1metro= del m=C3=B3dulo, es +obligatorio realizar pruebas con la configuraci=C3=B3n correspondiente. + +Tenga en cuenta que las autopruebas de KVM y las pruebas de unidad de KVM +tienen fallos conocidos. Si sospecha que un fallo no se debe a sus cambios, +verifique que el *exactamente el mismo* fallo se produce con y sin sus +cambios. + +Los cambios que afecten a la documentaci=C3=B3n de texto reestructurado, es +decir, a los archivos .rst, deben generar htmldocs de forma limpia, es +decir, sin advertencias ni errores. + +Si no puede probar completamente un cambio, por ejemplo, por falta de +hardware, indique claramente qu=C3=A9 nivel de pruebas ha podido realizar,= por +ejemplo, en la carta de presentaci=C3=B3n. + +Novedades +~~~~~~~~~ +Con una excepci=C3=B3n, las nuevas caracter=C3=ADsticas *deben* venir con = cobertura +de pruebas. Las pruebas espec=C3=ADficas de KVM no son estrictamente neces= arias, +por ejemplo, si la cobertura se proporciona mediante la ejecuci=C3=B3n de = una +prueba de VM hu=C3=A9sped suficientemente habilitada, o ejecutando una +autoprueba de kernel relacionada en una VM, pero en todos los casos se +prefieren las pruebas KVM dedicadas. Los casos de prueba negativos en +particular son obligatorios para la habilitaci=C3=B3n de nuevas caracter= =C3=ADsticas +de hardware, ya que los flujos de errores y excepciones rara vez se +ejercitan simplemente ejecutando una VM. + +La =C3=BAnica excepci=C3=B3n a esta regla es si KVM est=C3=A1 simplemente = anunciando +soporte para un a trav=C3=A9s de KVM_GET_SUPPORTED_CPUID, es decir, para +instrucciones/funciones que KVM no puede impedir que utilice una VM y +para las que no existe una verdadera habilitaci=C3=B3n. + +Tenga en cuenta que "nuevas caracter=C3=ADsticas" no significa s=C3=B3lo "= nuevas +caracter=C3=ADsticas de hardware". Las nuevas funcionalidades que no pueda= n ser +validadas usando las pruebas existentes de KVM y/o las pruebas unitarias de +KVM deben venir con pruebas. + +Es m=C3=A1s que bienvenido el env=C3=ADo de nuevos desarrollos de caracter= =C3=ADsticas sin +pruebas para obtener un feedback temprano, pero tales env=C3=ADos deben ser +etiquetados como RFC, y la carta de presentaci=C3=B3n debe indicar clarame= nte +qu=C3=A9 tipo de feedback se solicita/espera. No abuse del proceso de RFC;= las +RFC no suelen recibir una revisi=C3=B3n en profundidad. + +Correcci=C3=B3n de Errores +~~~~~~~~~~~~~~~~~~~~~ +Salvo en el caso de fallos "obvios" detectados por inspecci=C3=B3n, las +correcciones deben ir acompa=C3=B1adas de un reproductor del fallo corregi= do. En +muchos casos, el reproductor est=C3=A1 impl=C3=ADcito, por ejemplo, para e= rrores de +compilaci=C3=B3n y fallos de prueba, pero debe quedar claro para lectores = qu=C3=A9 es +lo que no funciona y c=C3=B3mo verificar la soluci=C3=B3n. Se concede cier= to margen a +los errores detectados mediante cargas de trabajo/pruebas no p=C3=BAblicas= , pero +se recomienda encarecidamente que se faciliten pruebas de regresi=C3=B3n p= ara +dichos errores. + +En general, las pruebas de regresi=C3=B3n son preferibles para cualquier f= allo +que no sea trivial de encontrar. Por ejemplo, incluso si el error fue +encontrado originalmente por un fuzzer como syzkaller, una prueba de +regresi=C3=B3n dirigida puede estar justificada si el error requiere golpe= ar una +condici=C3=B3n de carrera de tipo uno en un mill=C3=B3n. + +Recuerde que los fallos de KVM rara vez son urgentes *y* no triviales de +reproducir. Preg=C3=BAntate si un fallo es realmente el fin del mundo ante= s de +publicar una correcci=C3=B3n sin un reproductor. + +Publicaci=C3=B3n +----------- + +Enlaces +~~~~~~~ +No haga referencia expl=C3=ADcita a informes de errores, versiones anterio= res de +un parche/serie, etc. mediante cabeceras ``In-Reply-To:``. Usar +``In-Reply-To:`` se convierte en un l=C3=ADo para grandes series y/o cuand= o el +n=C3=BAmero de versiones es alto, y ``In-Reply-To:`` es in=C3=BAtil para c= ualquiera +que no tenga el mensaje original, por ejemplo, si alguien no recibi=C3=B3 = un Cc +en el informe de error o si la lista de destinatarios cambia entre +versiones. + +Para enlazar con un informe de error, una versi=C3=B3n anterior o cualquie= r cosa +de inter=C3=A9s, utiliza enlaces lore. Para hacer referencia a versiones +anteriores, en general no incluya un Enlace: en el registro de cambios, ya +que no hay necesidad de registrar la historia en git, es decir, ponga el +enlace en la carta de presentaci=C3=B3n o en la secci=C3=B3n que git ignor= a. +Proporcione un Enlace: formal para los informes de errores y/o discusiones +que condujeron al parche. El contexto de por qu=C3=A9 se hizo un cambio es= muy +valioso para futuros lectores. + +Basado en Git +~~~~~~~~~~~~~ +Si utilizas la versi=C3=B3n 2.9.0 o posterior de git (Googlers, =C2=A1os i= ncluimos a +todos!), utilice ``git format-patch`` con el indicador ``--base`` para +incluir autom=C3=A1ticamente la informaci=C3=B3n del =C3=A1rbol base en lo= s parches +generados. + +Tenga en cuenta que ``--base=3Dauto`` funciona como se espera si y s=C3=B3= lo si el +upstream de una rama se establece en la rama tem=C3=A1tica base, por ejemp= lo, +har=C3=A1 lo incorrecto si su upstream se establece en su repositorio pers= onal +con fines de copia de seguridad. Una soluci=C3=B3n "autom=C3=A1tica" alter= nativa es +derivar los nombres de tus ramas de desarrollo bas=C3=A1ndose en su KVM x8= 6, e +introd=C3=BAzcalo en ``--base``. Por ejemplo, ``x86/pmu/mi_nombre_de_rama`= `, y +luego escribir un peque=C3=B1o wrapper para extraer ``pmu`` del nombre de = la +rama actual para obtener ``--base=3Dx/pmu``, donde ``x`` es el nombre que = su +repositorio utiliza para rastrear el remoto KVM x86. + +Tests de Co-Publicaci=C3=B3n +~~~~~~~~~~~~~~~~~~~~~~~ +Las autopruebas de KVM asociadas a cambios de KVM, por ejemplo, pruebas de +regresi=C3=B3n para correcciones de errores, deben publicarse junto con los +cambios de KVM como una =C3=BAnica serie. Se aplicar=C3=A1n las reglas est= =C3=A1ndar del +n=C3=BAcleo para la bisecci=C3=B3n, es decir, los cambios de KVM que provo= quen fallos +en las pruebas se ordenar=C3=A1n despu=C3=A9s de las actualizaciones de las +autopruebas, y viceversa. Las pruebas que fallan debido a errores de KVM +deben ordenarse despu=C3=A9s de las correcciones de KVM. + +KVM-unit-tests deber=C3=ADa *siempre* publicarse por separado. Las herrami= entas, +por ejemplo b4 am, no saben que KVM-unit-tests es un repositorio separado y +se confunden cuando los parches de una serie se aplican en diferentes +=C3=A1rboles. Para vincular los parches de KVM-unit-tests a Parches KVM, p= rimero +publique los cambios KVM y luego proporcione un enlace lore Link: al +parche/serie KVM en el parche(s) KVM-unit-tests. + +Notificaciones +~~~~~~~~~~~~~~ +Cuando se acepte oficialmente un parche/serie, se enviar=C3=A1 un correo +electr=C3=B3nico de notificaci=C3=B3n en respuesta a la publicaci=C3=B3n o= riginal (carta +de presentaci=C3=B3n para series de varios parches). La notificaci=C3=B3n = incluir=C3=A1 el +=C3=A1rbol y la rama tem=C3=A1tica, junto con los SHA1 de los commits de l= os parches +aplicados. + +Si se aplica un subconjunto de parches, se indicar=C3=A1 claramente en la +notificaci=C3=B3n. A menos que se indique lo contrario, se sobreentiende q= ue +todos los parches del Las series que no han sido aceptadas necesitan m=C3= =A1s +trabajo y deben presentarse en una nueva versi=C3=B3n. + +Si por alguna raz=C3=B3n se retira un parche despu=C3=A9s de haber sido ac= eptado +oficialmente, se enviar=C3=A1 una respuesta al correo electr=C3=B3nico de +notificaci=C3=B3n explicando por qu=C3=A9 se ha retirado el parche, as=C3= =AD como los +pasos siguientes. + +Estabilidad SHA1 +~~~~~~~~~~~~~~~~ +Los SHA1 no son 100% estables hasta que llegan al =C3=A1rbol de Linus. Un = SHA1 +es *normalmente* estable una vez que se ha enviado una notificaci=C3=B3n, = pero +ocurren cosas. En la mayor=C3=ADa de los casos, se proporcionar=C3=A1 una +actualizaci=C3=B3n del correo electr=C3=B3nico de notificaci=C3=B3n si se = aplica un SHA1 +del parche. Sin embargo, en algunos escenarios, por ejemplo, si todas las +ramas de KVM x86 necesitan ser rebasadas, no se dar=C3=A1n notificaciones +individuales. + +Vulnerabilidades +~~~~~~~~~~~~~~~~ +Los fallos que pueden ser explotados por la VM (el "guest") para atacar al +host (kernel o espacio de usuario), o que pueden ser explotados por una VM +anidada a *su* host (L2 atacando a L1), son de particular inter=C3=A9s par= a KVM. +Por favor, siga el protocolo para :ref:`securitybugs` si sospecha que un +fallo puede provocar una filtraci=C3=B3n de datos, etc. + --=20 2.43.0