WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

RE: [Xen-users] AMD's VT for chipsets

To: "Gregory Gee" <gregory.gee@xxxxxxxxxxxx>
Subject: RE: [Xen-users] AMD's VT for chipsets
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Thu, 5 Oct 2006 11:51:39 +0200
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 05 Oct 2006 08:44:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <452455A0.800@xxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcboF4yS7NV5FPJZTPyEaY2HxSIjmgATBjtw
Thread-topic: [Xen-users] AMD's VT for chipsets
 

> -----Original Message-----
> From: Gregory Gee [mailto:gregory.gee@xxxxxxxxxxxx] 
> Sent: 05 October 2006 01:45
> To: Petersson, Mats
> Cc: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-users] AMD's VT for chipsets
> 
> Petersson, Mats wrote:
> >  
> >
> >   
> >> -----Original Message-----
> >> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
> >> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> >> Gregory Gee
> >> Sent: 04 October 2006 14:20
> >> To: xen-users@xxxxxxxxxxxxxxxxxxx
> >> Subject: Re: [Xen-users] AMD's VT for chipsets
> >>
> >> Thorolf Godawa wrote:
> >>     
> >>> Hi,
> >>>
> >>>       
> >>>> I'm not sure if it's part of the translation or some 
> other sort of
> >>>> misunderstanding, but chipsets (non-processor components) are not
> >>>> necessary for the AMD-V technology (formerly Pacifica) to operate
> >>>>         
> >>> I think he means s.th. related to the problem of the 
> >>>       
> >> virtualisation of 
> >>     
> >>> the i/o that the AMD-CPUs should do better than the first 
> >>> Intel-implementation of VT.
> >>>
> >>> AMD calls this "AMD I/O Virtualization Technology (IOMMU) 
> >>> Specification", you find a PDF here: 
> >>>
> >>>       
> >> http://www.amd.com/us-en/assets/content_type/white_papers_and_
> >> tech_docs/34434.pdf 
> >>     
> >>> The "Intel Virtualization Technology for Directed I/O 
> >>>       
> >> (VTd)" should be 
> >>     
> >>> implemented in a later version of Intel-VT (see PDF: 
> >>>
> >>>       
> >> ftp://download.intel.com/technology/computing/vptech/Intel(r)_
> >> VT_for_Direct_IO.pdf 
> >>     
> >>> ).
> >>>
> >>> But actually I don't know the status of this technique too and if 
> >>> there are really advantages for the user right now!
> >>>       
> >>   Wouldn't this allow PCI pass-through for SVM which isn't 
> possible 
> >> today?  I find PCI pas-through really useful but I can't 
> use it for 
> >> Windows guest in SVM.
> >>     
> >
> > Yes, that and better security are the two key points of this type of
> > technology. 
> >
> > The problem with PCI pass-through is that the fully-virtualized OS
> > doesn't know the machine physical address, so when it tries 
> to tell the
> > PCI device that it's got some data to work on, it gives the guest
> > physical address - which is most likely NOT the machine physical
> > address. IOMMU allows the mapping of DMA-memory from guest-physical
> > address to machine-physical address. 
> >
> > Since we can allow and disallow individual pages to be target to
> > PCI-devices (or any other IO-devices), it allows for better 
> security in
> > the system, since a device that has a bug or security hole 
> will still be
> > prevented from reading/writing addresses that aren't specifically
> > indicated as "allowed". Just like the MMU inside the CPU allows the
> > application to access some pieces of memory, whilst others are not
> > allowed to be accessed. 
> >
> > --
> > Mats
> >   
> 
>   Great, two questions.
> 
> 1.  Would this allow a PCI device that is not supported in 
> Linux to be 
> used in a Windows SVM dom?

Yes, there's no reason why support in Linux should have anything to do
with things here - the device driver in Windows would be the only driver
ever accessing the hardware - you'd have to "hide" it from Dom0 to use
it in DomU anyways, so Dom0 would never see that device. 

> 
> 2. When and would it be available for consumer boards or only Operton 
> and high end MB?

Don't know - I would think all types of platforms would get this feature
- but that's just guessing... 

--
Mats
> 
> Thanks,
> Greg
> 
> 
> 
> 



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>