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

Re: [Xen-users] is Intel VT-d "really" necessary?

  • To: Nick Couchman <Nick.Couchman@xxxxxxxxx>
  • From: Bruce Edge <bruce.edge@xxxxxxxxx>
  • Date: Wed, 15 Sep 2010 09:33:23 -0700
  • Cc: rudi@xxxxxxxxxxx, xen-users <xen-users@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 15 Sep 2010 09:34:52 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AJuvqdjvteJSHCvEJpwVR6KiKpQolZBAhQlFl8FSXqCuY/8hUmdeqV7WFYbypHwDID 8LvoVhyDEKuejnd6dziWeoxgUYu9EwkZksvlpP3aZ/oBf4k0tJVeaVrDbozcV45B1s5Q OR1E7hzMx2xWtKZX47e2FgeHmAL60k3w7dv5M=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

On Wed, Sep 15, 2010 at 7:38 AM, Nick Couchman <Nick.Couchman@xxxxxxxxx> wrote:
>>>> On 2010/09/15 at 03:20, Rudi Ahlers <Rudi@xxxxxxxxxxx> wrote:
>> Hi all,
>> I'm just curios and would like some input from the community on this
>> one. We're busy budgeting for a couple of new servers and I thought it
>> would be good to try out the Core i7 CPU's, but see the majority of
>> them don't offer VT-d, but just VT-x. Looking at the LGA1366 range,
>> only the "Intel lga1366 i7 980XE" (from the list of what our suppliers
>> stock) have VT-d, and it costs 4x more than "Intel lga1366 i7 930" or
>> 2x more than "Intel lga1366 i7 960". From a budget perspecitve I could
>> purchase 4 more CPU's, which could translate to 40x - 80x more VM's
>> being hosted for the same capital outlay. Experience has shown that we
>> under-utilize CPU's by a great margin and memory / HDD IO is our
>> biggest bottleneck on any server.
> That's interesting...is it the motherboards you're seeing this lack of 
> support on, or the chips?  I'm pretty sure the i7 processors themselves 
> support VTd, you just have to have the BIOS and MB support for it.
>> So, if VT-d really necessary?
>> We mainly host XEN virtual machine for the hosting industry, i.e. we
>> don't need / use graphics rendering inside VM's, or need DAS on the
>> VM's, etc.
> In an environment where you're planning on running many VMs on a single host, 
> I don't imagine VTd is going to be very helpful to you.  I use it here where 
> I work, but I use it on desktop systems where folks need access to graphics 
> cards, serial cards, etc., from Windows, and not on my server systems.  It 
> really depends on what you're doing as to whether you think you'll need it or 
> not - if you cannot think of a situation where *any* type of PCI card needs 
> to be forwarded through to an HVM domU, then you're probably okay without it. 
>  The few situations I can think of are:
> - Serial port cards, but this is really more common on desktops
> - Phone/Voicemail systems - If you're using any sort of telephony card with 
> an HVM domU you'll need direct PCI access, which requires VTd.
> - Other, vendor-specific add-in PCI cards, for applications like industrial 
> automation, etc.  But you won't see much of this in a data center.
> Also, keep in mind that, IIRC, PV domUs can access PCI devices without VTd, 
> so if you're going to be running PV kernels on these systems, or the PV 
> kernels you're running are the ones that need access to the PCI devices, then 
> you're probably fine without it.  I'm sure it offers some performance 
> enhancements over software-based IOMMU, but I don't know what those are.
> -Nick

Apologies in advance for hyjacking your thread, but this is an
interesting question.

For cases where PCI passthougth is the heart of the application, is it
better to use hvm/VTd or pv-ops/iommu=soft? Or is there some other
combination where you can still leverage VTd from pv-ops?


> --------
> This e-mail may contain confidential and privileged material for the sole use 
> of the intended recipient.  If this email is not intended for you, or you are 
> not responsible for the delivery of this message to the intended recipient, 
> please note that this message may contain SEAKR Engineering (SEAKR) 
> Privileged/Proprietary Information.  In such a case, you are strictly 
> prohibited from downloading, photocopying, distributing or otherwise using 
> this message, its contents or attachments in any way.  If you have received 
> this message in error, please notify us immediately by replying to this 
> e-mail and delete the message from your mailbox.  Information contained in 
> this message that does not relate to the business of SEAKR is neither 
> endorsed by nor attributable to SEAKR.
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users

Xen-users mailing list



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