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

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

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