> ce qui signifie un overhead pour émuler le comportement de ces composants, alors que l'idéal serait d'exploiter le vrai matériel au plus près
Non, à partir du moment où tu dois émuler, tu n'as (quasiment) aucun interêt à suivre ce qu'il y dessous.
Une approche intéressante pour ce genre de problème est que l'émulateur fournisse un accès direct au matériel sous jacent. Cela est faisable en USB (qemu le fait, vmware également); cependant, en PCI, cela pose des problèmes de mapping mémoire et imposerait au mieux des drivers plus ou moins prévu pour (et c'est p-e même impossible dans certains cas). Je ne sais pas si les extensions VT & SVM apportent qqchose à ce niveau là (proxy de périphériques), mais je n'ai rien vu, donc je suis sceptique.
Pour le cas de l'opengl, un patch était passé sur la mailing list : http://lists.gnu.org/archive/html/qemu-devel/2006-11/msg0014(...) . En gros, il s'agit d'un proxy opengl, qui fait passer les requêtes à l'host. Cela nécessite un support soft dans le client; je n'ai rien vu passer pour windows. Je crois que vmware le permet par contre.
Quand à écrire des pilotes pour, c'est effectivement pratique comme approche, mais manifestement ça n'a intéressé personne suffisament :) p-e voir ce qu'il y a dans virtualbox. Cependant et comme tu le fais remarquer, à partir du moment où c'est pour un OS libre, vaut mieux tout adapter pour faire de la paravirtualisation (à la xen donc). Cela dit, pour le cas de l'affichage, ça reste problèmatique, vu que tu as très peu de marge sur ce que tu peux faire pour des questions de performance.
[^] # Re: Noyau Linux 2.6.20 et KVM
Posté par Pierre Palatin . En réponse à la dépêche kqemu devient libre, qemu 0.9.0. Évalué à 4.
Non, à partir du moment où tu dois émuler, tu n'as (quasiment) aucun interêt à suivre ce qu'il y dessous.
Une approche intéressante pour ce genre de problème est que l'émulateur fournisse un accès direct au matériel sous jacent. Cela est faisable en USB (qemu le fait, vmware également); cependant, en PCI, cela pose des problèmes de mapping mémoire et imposerait au mieux des drivers plus ou moins prévu pour (et c'est p-e même impossible dans certains cas). Je ne sais pas si les extensions VT & SVM apportent qqchose à ce niveau là (proxy de périphériques), mais je n'ai rien vu, donc je suis sceptique.
Pour le cas de l'opengl, un patch était passé sur la mailing list : http://lists.gnu.org/archive/html/qemu-devel/2006-11/msg0014(...) . En gros, il s'agit d'un proxy opengl, qui fait passer les requêtes à l'host. Cela nécessite un support soft dans le client; je n'ai rien vu passer pour windows. Je crois que vmware le permet par contre.
Quand à écrire des pilotes pour, c'est effectivement pratique comme approche, mais manifestement ça n'a intéressé personne suffisament :) p-e voir ce qu'il y a dans virtualbox. Cependant et comme tu le fais remarquer, à partir du moment où c'est pour un OS libre, vaut mieux tout adapter pour faire de la paravirtualisation (à la xen donc). Cela dit, pour le cas de l'affichage, ça reste problèmatique, vu que tu as très peu de marge sur ce que tu peux faire pour des questions de performance.