1 .. include:: ../disclaimer-sp.rst 2 3 :Original: Documentation/process/maintainer-kvm-x86.rst 4 :Translator: Juan Embid <jembid@ucm.es> 5 6 KVM x86 7 ======= 8 9 Prólogo 10 -------- 11 KVM se esfuerza por ser una comunidad acogedora; las contribuciones de los 12 recién llegados son valoradas e incentivadas. Por favor, no se desanime ni 13 se sienta intimidado por la extensión de este documento y las numerosas 14 normas/directrices que contiene. Todos cometemos errores y todos hemos sido 15 principiantes en algún momento. Mientras haga un esfuerzo honesto por 16 seguir las directrices de KVM x86, sea receptivo a los comentarios, y 17 aprenda de los errores que cometa, será recibido con los brazos abiertos, 18 no con antorchas y horcas. 19 20 TL;DR 21 ----- 22 Las pruebas son obligatorias. Sea coherente con los estilos y patrones 23 establecidos. 24 25 Árboles 26 ------- 27 KVM x86 se encuentra actualmente en un período de transición de ser parte 28 del árbol principal de KVM, a ser "sólo otra rama de KVM". Como tal, KVM 29 x86 está dividido entre el árbol principal de KVM, 30 ``git.kernel.org/pub/scm/virt/kvm/kvm.git``, y un árbol específico de KVM 31 x86, ``github.com/kvm-x86/linux.git``. 32 33 Por lo general, las correcciones para el ciclo en curso se aplican 34 directamente al árbol principal de KVM, mientras que todo el desarrollo 35 para el siguiente ciclo se dirige a través del árbol de KVM x86. En el 36 improbable caso de que una corrección para el ciclo actual se dirija a 37 través del árbol KVM x86, se aplicará a la rama ``fixes`` antes de llegar 38 al árbol KVM principal. 39 40 Tenga en cuenta que se espera que este periodo de transición dure bastante 41 tiempo, es decir, que será el statu quo en un futuro previsible. 42 43 Ramas 44 ~~~~~ 45 El árbol de KVM x86 está organizado en múltiples ramas por temas. El 46 propósito de utilizar ramas temáticas más específicas es facilitar el 47 control de un área de desarrollo, y para limitar los daños colaterales de 48 errores humanos y/o commits con errores, por ejemplo, borrar el commit HEAD 49 de una rama temática no tiene impacto en los hashes SHA1 de otros commit 50 en en camino, y tener que rechazar una solicitud de pull debido a errores 51 retrasa sólo esa rama temática. 52 53 Todas las ramas temáticas, excepto ``next`` y ``fixes``, se agrupan en 54 ``next`` a través de un Cthulhu merge en función de las necesidades, es 55 decir, cuando se actualiza una rama temática. Como resultado, los push 56 forzados a ``next`` son comunes. 57 58 Ciclo de Vida 59 ~~~~~~~~~~~~~ 60 Las correcciones dirigidas a la versión actual, también conocida como 61 mainline, suelen aplicarse directamente al árbol principal de KVM, es 62 decir, no pasan por el árbol x86 de KVM. 63 64 Los cambios dirigidos a la siguiente versión se dirigen a través del árbol 65 KVM x86. Se envían pull requests (de KVM x86 a KVM main) para cada rama 66 temática de KVM x86, normalmente la semana antes de que Linus abra la 67 ventana de fusión, por ejemplo, la semana siguiente a rc7 para las 68 versiones "normales". Si todo va bien, las ramas temáticas son subidas en 69 el pull request principal de KVM enviado durante la ventana de fusión de 70 Linus. 71 72 El árbol de KVM x86 no tiene su propia ventana de fusión oficial, pero hay 73 un cierre suave alrededor de rc5 para nuevas características, y un cierre 74 suave alrededor de rc6 para correcciones (para la próxima versión; fíjese 75 más arriba para las correcciones dirigidas a la versión actual). 76 77 Cronología 78 ~~~~~~~~~~ 79 Normalmente, los envíos se revisan y aplican en orden FIFO, con cierto 80 margen de maniobra en función del tamaño de la serie, los parches que están 81 "calientes en caché", etc. Correcciones, especialmente para la versión 82 actual y/o árboles estables, consiguen saltar la cola. Los parches que se 83 lleven a través de un árbol que no sea KVM (la mayoría de las veces a 84 través del árbol de consejos) y/o que tengan otros acks/revisiones también 85 saltan la cola hasta cierto punto. 86 87 Tenga en cuenta que la mayor parte de la revisión se realiza entre rc1 y 88 rc6, más o menos. El periodo entre la rc6 y la siguiente rc1 se utiliza 89 para ponerse al día en otras tareas, es decir, la falta de envíos durante 90 este periodo no es inusual. 91 92 Los pings para obtener una actualización del estado son bienvenidos, pero 93 tenga en cuenta el calendario del ciclo de publicación actual y tenga 94 expectativas realistas. Si está haciendo ping para la aceptación, es decir, 95 no sólo para obtener comentarios o una actualización, por favor haga todo 96 lo posible, dentro de lo razonable, para asegurarse de que sus parches 97 están listos para ser fusionados. Los pings sobre series que rompen la 98 compilación o fallan en las pruebas provocan el descontento de los 99 mantenedores. 100 101 Desarrollo 102 ----------- 103 104 Árbol base/Rama 105 ~~~~~~~~~~~~~~~ 106 Las correcciones dirigidas a la versión actual, también conocida como 107 mainline, deben basarse en 108 ``git://git.kernel.org/pub/scm/virt/kvm/kvm.git master``. Tenga en cuenta 109 que las correcciones no garantizan automáticamente la inclusión en la 110 versión actual. No hay una regla única, pero normalmente sólo las 111 correcciones de errores urgentes, críticos y/o introducidos en la versión 112 actual deberían incluirse en la versión actual. 113 114 Todo lo demás debería basarse en ``kvm-x86/next``, es decir, no hay 115 necesidad de seleccionar una rama temática específica como base. Si hay 116 conflictos y/o dependencias entre ramas, es trabajo del mantenedor 117 resolverlos. 118 119 La única excepción al uso de ``kvm-x86/next`` como base es si un 120 parche/serie es una serie multi-arquitectura, es decir, tiene 121 modificaciones no triviales en el código común de KVM y/o tiene cambios más 122 que superficiales en el código de otras arquitecturas. Los parches/series 123 multi-arquitectura deberían basarse en un punto común y estable en la 124 historia de KVM, por ejemplo, la versión candidata en la que se basa 125 ``kvm-x86 next``. Si no está seguro de si un parche/serie es realmente 126 multiarquitectura, sea precavido y trátelo como multiarquitectura, es 127 decir, utilice una base común. 128 129 Estilo del codigo 130 ~~~~~~~~~~~~~~~~~~~~~~ 131 Cuando se trata de estilo, nomenclatura, patrones, etc., la coherencia es 132 la prioridad número uno en KVM x86. Si todo lo demás falla, haga coincidir 133 lo que ya existe. 134 135 Con algunas advertencias que se enumeran a continuación, siga las 136 recomendaciones de los responsables del árbol de consejos 137 :ref:`maintainer-tip-coding-style`, ya que los parches/series a menudo 138 tocan tanto archivos x86 KVM como no KVM, es decir, llaman la atención de 139 los mantenedores de KVM *y* del árbol de consejos. 140 141 El uso del abeto inverso, también conocido como árbol de Navidad inverso o 142 árbol XMAS inverso, para las declaraciones de variables no es estrictamente 143 necesario, aunque es preferible. 144 145 Excepto para unos pocos apuntes especiales, no utilice comentarios 146 kernel-doc para las funciones. La gran mayoría de las funciones "públicas" 147 de KVM no son realmente públicas, ya que están destinadas únicamente al 148 consumo interno de KVM (hay planes para privatizar las cabeceras y 149 exportaciones de KVM para reforzar esto). 150 151 Comentarios 152 ~~~~~~~~~~~ 153 Escriba los comentarios en modo imperativo y evite los pronombres. Utilice 154 los comentarios para ofrecer una visión general de alto nivel del código 155 y/o para explicar por qué el código hace lo que hace. No reitere lo que el 156 código hace literalmente; deje que el código hable por sí mismo. Si el 157 propio código es inescrutable, los comentarios no servirán de nada. 158 159 Referencias SDM y APM 160 ~~~~~~~~~~~~~~~~~~~~~~ 161 Gran parte de la base de código de KVM está directamente vinculada al 162 comportamiento de la arquitectura definido en El Manual de Desarrollo de 163 Software (SDM) de Intel y el Manual del Programador de Arquitectura (APM) 164 de AMD. El uso de "SDM de Intel" y "APM de AMD", o incluso sólo "SDM" o 165 "APM", sin contexto adicional es correcto. 166 167 No haga referencia a secciones específicas, tablas, figuras, etc. por su 168 número, especialmente en los comentarios. En su lugar, si es necesario 169 (véase más abajo), copie y pegue el fragmento correspondiente y haga 170 referencia a las secciones/tablas/figuras por su nombre. Los diseños del 171 SDM y el APM cambian constantemente, por lo que los números/etiquetas no 172 son estables. 173 174 En general, no haga referencia explícita ni copie-pegue del SDM o APM en 175 los comentarios. Con pocas excepciones, KVM *debe* respetar el 176 comportamiento de la arquitectura, por lo que está implícito que el 177 comportamiento de KVM está emulando el comportamiento de SDM y/o APM. Tenga 178 en cuenta que hacer referencia al SDM/APM en los registros de cambios para 179 justificar el cambio y proporcionar contexto es perfectamente correcto y 180 recomendable. 181 182 Shortlog 183 ~~~~~~~~ 184 El formato de prefijo más recomendable es ``KVM: <topic>:``, donde 185 ``<topic>`` es uno de los siguientes:: 186 187 - x86 188 - x86/mmu 189 - x86/pmu 190 - x86/xen 191 - autocomprobaciones 192 - SVM 193 - nSVM 194 - VMX 195 - nVMX 196 197 **¡NO use x86/kvm!** ``x86/kvm`` se usa exclusivamente para cambios de 198 Linux virtualizado por KVM, es decir, para arch/x86/kernel/kvm.c. No use 199 nombres de archivos o archivos completos como prefijo de asunto/shortlog. 200 201 Tenga en cuenta que esto no coincide con las ramas temáticas (las ramas 202 temáticas se preocupan mucho más por los conflictos de código). 203 204 Todos los nombres distinguen entre mayúsculas y minúsculas. ``KVM: x86:`` 205 es correcto, ``kvm: vmx:`` no lo es. 206 207 Escriba en mayúsculas la primera palabra de la descripción condensada del 208 parche, pero omita la puntuación final. Por ejemplo:: 209 210 KVM: x86: Corregir una desviación de puntero nulo en function_xyz() 211 212 no:: 213 214 kvm: x86: corregir una desviación de puntero nulo en function_xyz. 215 216 Si un parche afecta a varios temas, recorra el árbol conceptual hasta 217 encontrar el primer padre común (que suele ser simplemente ``x86``). En 218 caso de duda, ``git log path/to/file`` debería proporcionar una pista 219 razonable. 220 221 De vez en cuando surgen nuevos temas, pero le rogamos que inicie un debate 222 en la lista si desea proponer la introducción de un nuevo tema, es decir, 223 no se ande con rodeos. 224 225 Consulte :ref:`the_canonical_patch_format` para obtener más información, 226 con una enmienda: no trate el límite de 70-75 caracteres como un límite 227 absoluto y duro. En su lugar, utilice 75 caracteres como límite firme, pero 228 no duro, y 80 caracteres como límite duro. Es decir, deje que el registro 229 corto sobrepase en algunos caracteres el límite estándar si tiene una buena 230 razón para hacerlo. 231 232 Registro de cambios 233 ~~~~~~~~~~~~~~~~~~~ 234 Y lo que es más importante, escriba los registros de cambios en modo 235 imperativo y evite los pronombres. 236 237 Consulte :ref:`describe_changes` para obtener más información, con una 238 recomendación: comience con un breve resumen de los cambios reales y 239 continúe con el contexto y los antecedentes. Nota. Este orden entra en 240 conflicto directo con el enfoque preferido del árbol de sugerencias. Por 241 favor, siga el estilo preferido del árbol de sugerencias cuando envíe 242 parches. que se dirigen principalmente a código arch/x86 que _NO_ es código 243 KVM. 244 245 KVM x86 prefiere indicar lo que hace un parche antes de entrar en detalles 246 por varias razones. En primer lugar, el código que realmente se está 247 cambiando es posiblemente la información más importante, por lo que esa 248 información debe ser fácil de encontrar. Changelogs que entierran el "qué 249 está cambiando realmente" en una sola línea después de 3+ párrafos de fondo 250 hacen muy difícil encontrar esa información. 251 252 Para la revisión inicial, se podría argumentar que "lo que está roto" es 253 más importante, pero para hojear los registros y la arqueología git, los 254 detalles escabrosos importan cada vez menos. Por ejemplo, al hacer una 255 serie de "git blame", los detalles de cada cambio a lo largo del camino son 256 inútiles, los detalles sólo importan para el culpable. Proporcionar el "qué 257 ha cambiado" facilita determinar rápidamente si una confirmación puede ser 258 de interés o no. 259 260 Otra ventaja de decir primero "qué cambia" es que casi siempre es posible 261 decir "qué cambia" en una sola frase. A la inversa, todo menos los errores 262 más simples requieren varias frases o párrafos para describir el problema. 263 Si tanto "qué está cambiando" como "cuál es el fallo" son muy breves, el 264 orden no importa. Pero si uno es más corto (casi siempre el "qué está 265 cambiando"), entonces cubrir el más corto primero es ventajoso porque es 266 menos inconveniente para los lectores/revisores que tienen una preferencia 267 estricta de orden. Por ejemplo, tener que saltarse una frase para llegar al 268 contexto es menos doloroso que tener que saltarse tres párrafos para llegar 269 a "lo que cambia". 270 271 Arreglos 272 ~~~~~~~~ 273 Si un cambio corrige un error de KVM/kernel, añada una etiqueta Fixes: 274 incluso si el cambio no necesita ser retroportado a kernels estables, e 275 incluso si el cambio corrige un error en una versión anterior. 276 277 Por el contrario, si es necesario hacer una corrección, etiquete 278 explícitamente el parche con "Cc: stable@vger.kernel" (aunque no es 279 necesario que el correo electrónico incluya Cc: stable); KVM x86 opta por 280 excluirse del backporting Correcciones: por defecto. Algunos parches 281 seleccionados automáticamente se retroportan, pero requieren la aprobación 282 explícita de los mantenedores (busque MANUALSEL). 283 284 Referencias a Funciones 285 ~~~~~~~~~~~~~~~~~~~~~~~ 286 Cuando se mencione una función en un comentario, registro de cambios o 287 registro abreviado (o en cualquier otro lugar), utilice el formato 288 ``nombre_de_la_función()``. Los paréntesis proporcionan contexto y 289 desambiguan la referencia. 290 291 Pruebas 292 ~~~~~~~ 293 Como mínimo, *todos* los parches de una serie deben construirse limpiamente 294 para KVM_INTEL=m KVM_AMD=m, y KVM_WERROR=y. Construir todas las 295 combinaciones posibles de Kconfigs no es factible, pero cuantas más mejor. 296 KVM_SMM, KVM_XEN, PROVE_LOCKING, y X86_64 son particularmente interesantes. 297 298 También es obligatorio ejecutar las autopruebas y las pruebas unitarias de 299 KVM (y, como es obvio, las pruebas deben pasar). La única excepción es para 300 los cambios que tienen una probabilidad insignificante de afectar al 301 comportamiento en tiempo de ejecución, por ejemplo, parches que sólo 302 modificar los comentarios. Siempre que sea posible y pertinente, se 303 recomienda encarecidamente realizar pruebas tanto en Intel como en AMD. Se 304 recomienda arrancar una máquina virtual real, pero no es obligatorio. 305 306 Para cambios que afecten al código de paginación en la sombra de KVM, es 307 obligatorio ejecutar con TDP (EPT/NPT) deshabilitado. Para cambios que 308 afecten al código MMU común de KVM, se recomienda encarecidamente ejecutar 309 con TDP deshabilitado. Para todos los demás cambios, si el código que se 310 está modificando depende de y/o interactúa con un parámetro del módulo, es 311 obligatorio realizar pruebas con la configuración correspondiente. 312 313 Tenga en cuenta que las autopruebas de KVM y las pruebas de unidad de KVM 314 tienen fallos conocidos. Si sospecha que un fallo no se debe a sus cambios, 315 verifique que el *exactamente el mismo* fallo se produce con y sin sus 316 cambios. 317 318 Los cambios que afecten a la documentación de texto reestructurado, es 319 decir, a los archivos .rst, deben generar htmldocs de forma limpia, es 320 decir, sin advertencias ni errores. 321 322 Si no puede probar completamente un cambio, por ejemplo, por falta de 323 hardware, indique claramente qué nivel de pruebas ha podido realizar, por 324 ejemplo, en la carta de presentación. 325 326 Novedades 327 ~~~~~~~~~ 328 Con una excepción, las nuevas características *deben* venir con cobertura 329 de pruebas. Las pruebas específicas de KVM no son estrictamente necesarias, 330 por ejemplo, si la cobertura se proporciona mediante la ejecución de una 331 prueba de VM huésped suficientemente habilitada, o ejecutando una 332 autoprueba de kernel relacionada en una VM, pero en todos los casos se 333 prefieren las pruebas KVM dedicadas. Los casos de prueba negativos en 334 particular son obligatorios para la habilitación de nuevas características 335 de hardware, ya que los flujos de errores y excepciones rara vez se 336 ejercitan simplemente ejecutando una VM. 337 338 La única excepción a esta regla es si KVM está simplemente anunciando 339 soporte para un a través de KVM_GET_SUPPORTED_CPUID, es decir, para 340 instrucciones/funciones que KVM no puede impedir que utilice una VM y 341 para las que no existe una verdadera habilitación. 342 343 Tenga en cuenta que "nuevas características" no significa sólo "nuevas 344 características de hardware". Las nuevas funcionalidades que no puedan ser 345 validadas usando las pruebas existentes de KVM y/o las pruebas unitarias de 346 KVM deben venir con pruebas. 347 348 Es más que bienvenido el envío de nuevos desarrollos de características sin 349 pruebas para obtener un feedback temprano, pero tales envíos deben ser 350 etiquetados como RFC, y la carta de presentación debe indicar claramente 351 qué tipo de feedback se solicita/espera. No abuse del proceso de RFC; las 352 RFC no suelen recibir una revisión en profundidad. 353 354 Corrección de Errores 355 ~~~~~~~~~~~~~~~~~~~~~ 356 Salvo en el caso de fallos "obvios" detectados por inspección, las 357 correcciones deben ir acompañadas de un reproductor del fallo corregido. En 358 muchos casos, el reproductor está implícito, por ejemplo, para errores de 359 compilación y fallos de prueba, pero debe quedar claro para lectores qué es 360 lo que no funciona y cómo verificar la solución. Se concede cierto margen a 361 los errores detectados mediante cargas de trabajo/pruebas no públicas, pero 362 se recomienda encarecidamente que se faciliten pruebas de regresión para 363 dichos errores. 364 365 En general, las pruebas de regresión son preferibles para cualquier fallo 366 que no sea trivial de encontrar. Por ejemplo, incluso si el error fue 367 encontrado originalmente por un fuzzer como syzkaller, una prueba de 368 regresión dirigida puede estar justificada si el error requiere golpear una 369 condición de carrera de tipo uno en un millón. 370 371 Recuerde que los fallos de KVM rara vez son urgentes *y* no triviales de 372 reproducir. Pregúntate si un fallo es realmente el fin del mundo antes de 373 publicar una corrección sin un reproductor. 374 375 Publicación 376 ----------- 377 378 Enlaces 379 ~~~~~~~ 380 No haga referencia explícita a informes de errores, versiones anteriores de 381 un parche/serie, etc. mediante cabeceras ``In-Reply-To:``. Usar 382 ``In-Reply-To:`` se convierte en un lío para grandes series y/o cuando el 383 número de versiones es alto, y ``In-Reply-To:`` es inútil para cualquiera 384 que no tenga el mensaje original, por ejemplo, si alguien no recibió un Cc 385 en el informe de error o si la lista de destinatarios cambia entre 386 versiones. 387 388 Para enlazar con un informe de error, una versión anterior o cualquier cosa 389 de interés, utiliza enlaces lore. Para hacer referencia a versiones 390 anteriores, en general no incluya un Enlace: en el registro de cambios, ya 391 que no hay necesidad de registrar la historia en git, es decir, ponga el 392 enlace en la carta de presentación o en la sección que git ignora. 393 Proporcione un Enlace: formal para los informes de errores y/o discusiones 394 que condujeron al parche. El contexto de por qué se hizo un cambio es muy 395 valioso para futuros lectores. 396 397 Basado en Git 398 ~~~~~~~~~~~~~ 399 Si utilizas la versión 2.9.0 o posterior de git (Googlers, ¡os incluimos a 400 todos!), utilice ``git format-patch`` con el indicador ``--base`` para 401 incluir automáticamente la información del árbol base en los parches 402 generados. 403 404 Tenga en cuenta que ``--base=auto`` funciona como se espera si y sólo si el 405 upstream de una rama se establece en la rama temática base, por ejemplo, 406 hará lo incorrecto si su upstream se establece en su repositorio personal 407 con fines de copia de seguridad. Una solución "automática" alternativa es 408 derivar los nombres de tus ramas de desarrollo basándose en su KVM x86, e 409 introdúzcalo en ``--base``. Por ejemplo, ``x86/pmu/mi_nombre_de_rama``, y 410 luego escribir un pequeño wrapper para extraer ``pmu`` del nombre de la 411 rama actual para obtener ``--base=x/pmu``, donde ``x`` es el nombre que su 412 repositorio utiliza para rastrear el remoto KVM x86. 413 414 Tests de Co-Publicación 415 ~~~~~~~~~~~~~~~~~~~~~~~ 416 Las autopruebas de KVM asociadas a cambios de KVM, por ejemplo, pruebas de 417 regresión para correcciones de errores, deben publicarse junto con los 418 cambios de KVM como una única serie. Se aplicarán las reglas estándar del 419 núcleo para la bisección, es decir, los cambios de KVM que provoquen fallos 420 en las pruebas se ordenarán después de las actualizaciones de las 421 autopruebas, y viceversa. Las pruebas que fallan debido a errores de KVM 422 deben ordenarse después de las correcciones de KVM. 423 424 KVM-unit-tests debería *siempre* publicarse por separado. Las herramientas, 425 por ejemplo b4 am, no saben que KVM-unit-tests es un repositorio separado y 426 se confunden cuando los parches de una serie se aplican en diferentes 427 árboles. Para vincular los parches de KVM-unit-tests a Parches KVM, primero 428 publique los cambios KVM y luego proporcione un enlace lore Link: al 429 parche/serie KVM en el parche(s) KVM-unit-tests. 430 431 Notificaciones 432 ~~~~~~~~~~~~~~ 433 Cuando se acepte oficialmente un parche/serie, se enviará un correo 434 electrónico de notificación en respuesta a la publicación original (carta 435 de presentación para series de varios parches). La notificación incluirá el 436 árbol y la rama temática, junto con los SHA1 de los commits de los parches 437 aplicados. 438 439 Si se aplica un subconjunto de parches, se indicará claramente en la 440 notificación. A menos que se indique lo contrario, se sobreentiende que 441 todos los parches del Las series que no han sido aceptadas necesitan más 442 trabajo y deben presentarse en una nueva versión. 443 444 Si por alguna razón se retira un parche después de haber sido aceptado 445 oficialmente, se enviará una respuesta al correo electrónico de 446 notificación explicando por qué se ha retirado el parche, así como los 447 pasos siguientes. 448 449 Estabilidad SHA1 450 ~~~~~~~~~~~~~~~~ 451 Los SHA1 no son 100% estables hasta que llegan al árbol de Linus. Un SHA1 452 es *normalmente* estable una vez que se ha enviado una notificación, pero 453 ocurren cosas. En la mayoría de los casos, se proporcionará una 454 actualización del correo electrónico de notificación si se aplica un SHA1 455 del parche. Sin embargo, en algunos escenarios, por ejemplo, si todas las 456 ramas de KVM x86 necesitan ser rebasadas, no se darán notificaciones 457 individuales. 458 459 Vulnerabilidades 460 ~~~~~~~~~~~~~~~~ 461 Los fallos que pueden ser explotados por la VM (el "guest") para atacar al 462 host (kernel o espacio de usuario), o que pueden ser explotados por una VM 463 anidada a *su* host (L2 atacando a L1), son de particular interés para KVM. 464 Por favor, siga el protocolo para :ref:`securitybugs` si sospecha que un 465 fallo puede provocar una filtración de datos, etc.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.