[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] VT-x and frontend/backend drivers

  • To: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Mark Ryden <markryde@xxxxxxxxx>
  • Date: Sun, 8 Jan 2006 13:49:10 +0200
  • Delivery-date: Sun, 08 Jan 2006 11:55:43 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=S63nNw40PLsCYGUSqNEU7IYbD6TaML5+EEasVU0mNOeDCVVLZoMWoxA30knzpKZIgUE//uB6UM2FlO3qDVQWEEoT01Kdjy6ookL/sm5VX+jFHp7pJq/TBczAVzo3sxpVcTzZSiau4q6msod/fPAQBmJ80V8PiR05WjeSkZrAYK8=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>


  As I saw in this mailing list, there should be some
        emulation solution for drivers when using VT-x processors.
See for example :
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)?

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.