Hello, As I saw in this mailing list, there should be some emulation solution for drivers when using VT-x processors. See for example : http://lists.xensource.com/archives/html/xen-devel/2005-12/msg00763.html My question is this; As I understand, the VMX support in the new VT-x processors enables us to prevent Guest OSs from performing unwanted instructions (HLT , for example). This is done by using the root and non-root VMX operation. Thus , we don''t use paravirtualization and we can run unmodified guest. Is there a possibility or any intention of using the backend-frontend solution of Xen (maybe with some fixes) when using VT-x processors ? wouldn''t it be much better in terms of performance than using hardware emulation (based on QEMU maybe)? Regards, --MR _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Thus , we don't use paravirtualization and we > can run unmodified guest. > Is there a possibility or any intention of using the > backend-frontend solution of Xen (maybe with some fixes) when using > VT-x processors ? wouldn't it be much better in terms of > performance than using hardware emulation (based on QEMU maybe)?Yes. PV drivers are a prerequisite for decent performance for fully virtualized guests on xen. -Kip _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Ryden wrote:> Hello, > > As I saw in this mailing list, there should be some > emulation solution for drivers when using VT-x processors. > > See for example : >http://lists.xensource.com/archives/html/xen-devel/2005-12/msg00763.html> > My question is this; > > As I understand, the VMX support in the new VT-x processors > enables us to prevent Guest OSs from performing > unwanted instructions (HLT , for example). This is > done by using the root and non-root VMX operation. > Thus , we don''t use paravirtualization and we > can run unmodified guest. > Is there a possibility or any intention of using the > backend-frontend solution of Xen (maybe with some fixes) when using > VT-x processors ? wouldn''t it be much better in terms of > performance than using hardware emulation (based on QEMU maybe)?Agree :) . This is a good way to improve VMX domain performance. Idealy, if we can implement the xen infrastructure (e.g. hypercall, event channel, memory map etc.) in kernel module, porting those frontend/backend drivers should be easy and may be only small modification. One challenge is the hypercall parameter passing. In DomU case, hypervisor can use copy_from_user/copy_to_user to pass hypercall parameter, since they are in the same address space. In VMX domain case, the domain use different address space than hypervisor, so the copy_**_user doesn''t work. Best Regards Ke> > Regards, > --MR > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
We already have patches for para-dirver support sent to this list before, you can search it if you need. Mark Ryden <> wrote:> Hello, > > As I saw in this mailing list, there should be some > emulation solution for drivers when using VT-x processors. > > See for example : > http://lists.xensource.com/archives/html/xen-devel/2005-12/msg00763.html > > My question is this; > > As I understand, the VMX support in the new VT-x processors > enables us to prevent Guest OSs from performing unwanted > instructions (HLT , for example). This is done by using the root > and non-root VMX operation. Thus , we don''t use paravirtualization > and we can run unmodified guest. Is there a possibility or any > intention of using the backend-frontend solution of Xen (maybe with > some fixes) when using VT-x processors ? wouldn''t it be much better > in terms of performance than using hardware emulation (based on QEMU > maybe)? > > Regards, > --MR > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel