[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?

-Bruce


>
>
> --------
> 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
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

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