Hi Xen-community! The german Wikipedia article about "AMD I/O Virtualization Technology" states the following: Differently from INTEL, it''s planned for 2006 to integrate AMDs Virtualization Technology into chipsets, to use the full potential of Virtualization -> http://de.wikipedia.org/wiki/Pacifica_(Computer) What will that mean for practical use? Are these mainboards still available? And if not, should we wait for them and buy new hardware components later, maybe in the next year? Does Xen support the chipsets yet? Thanks & kind regards, Mark Weinem _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> -----Original Message----- > From: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of > Mark Weinem > Sent: 02 October 2006 21:56 > To: xen-users@lists.xensource.com > Subject: [Xen-users] AMD''s VT for chipsets > > Hi Xen-community! > > The german Wikipedia article about "AMD I/O Virtualization > Technology" > states the following: > > Differently from INTEL, it''s planned for 2006 to integrate > AMDs > Virtualization Technology into chipsets, to use the full potential of > Virtualization > > -> http://de.wikipedia.org/wiki/Pacifica_(Computer) > > What will that mean for practical use? > Are these mainboards still available? And if not, should we > wait for them > and buy new hardware components later, maybe in the next > year? Does Xen > support the chipsets yet?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 correctly. It is available now in Opteron 1xxx, 2xxx and 8xxx; Athlon64[x2][FX] and Turion X2 processors that have DDR2 memory controller [it''s easiest to tell them apart by that factor - DDR2 was added to the same generation of processor as the AMD-V feature]. Unfortunately, these processors can not be used in the older motherboards, due to the DDR2 interface. I''m not entirely sure what the author considers to be "different from Intel" - it is a different implementation than Intel''s, but with very similar functionality - there is no difference in functionality in Xen [aside from wahtever bugs either side is suffering from in the implementation - as there is some code that isn''t shared, the bugs may be different on either side]. -- Mats> > > Thanks & kind regards, Mark Weinem > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Petersson, Mats:> 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 > correctly. It is available now in Opteron 1xxx, 2xxx and 8xxx; > Athlon64[x2][FX] and Turion X2 processors that have DDR2 memory > controllerThanks for your reply Mats! I know this, but the article states, that apart from the new processors. the integration of "AMD-V" into chipsets will make it possible to use the full potential of hardware-based Virtualization. If this is true (I found the statement only in the german article!), what will these "full potentials" or "optimizations" be in practical use? And when will the new chipsets and mainboards be available, this year, next year? And when - if ever - will Xen support them?> I''m not entirely sure what the author considers to be "different from > Intel"The difference is that Intel will not offer those chipsets. Greetings, Mark Weinem _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> -----Original Message----- > From: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of > Mark Weinem > Sent: 03 October 2006 13:12 > To: xen-users@lists.xensource.com > Subject: Re: [Xen-users] AMD''s VT for chipsets > > Petersson, Mats: > > > 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 > > correctly. It is available now in Opteron 1xxx, 2xxx and 8xxx; > > Athlon64[x2][FX] and Turion X2 processors that have DDR2 memory > > controller > > Thanks for your reply Mats! I know this, but the article states, that > apart from the new processors. the integration of "AMD-V" > into chipsets > will make it possible to use the full potential of hardware-based > Virtualization. > > If this is true (I found the statement only in the german > article!), what > will these "full potentials" or "optimizations" be in > practical use? And > when will the new chipsets and mainboards be available, this > year, next > year? And when - if ever - will Xen support them?Speculation (or factual based statements) on future products is not encouraged by AMD. However, I think this is referring to IOMMU, which is going to be part of chipsets in the future. It allows the virtual machine to have direct hardware access even when it''s fully-virtualized - by mapping the guest physical view into a machine physical view. I can''t say anything about any release dates or such, because I simply don''t know... As to if/when it will come as part of Xen - I guess it''s a pretty useful feature for a hypervisor to be able to give hardware access to the guest, so it would surprise me a lot if Xen DIDN''T implement this prety much to be ready for release of the hardware. But that''s speculation on someone elses product - which has a certain level of insecurity.> > > > I''m not entirely sure what the author considers to be > "different from > > Intel" > > The difference is that Intel will not offer those chipsets.Intel has announced support for IOMMU in some form, whether it''s identical, similar or different from the AMD one, I can''t say. I think AMD announced the IOMMU slightly earlier than Intel, so if the article was written between one and the other''s release, it may be the cause for difference. IOMMU isn''t that new - IBM already has one or two models available. -- Mats> > > Greetings, Mark Weinem > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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 operateI 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! -- Chau y hasta luego, Thorolf _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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. Greg _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> -----Original Message----- > From: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of > Gregory Gee > Sent: 04 October 2006 14:20 > To: xen-users@lists.xensource.com > 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> > Greg > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Petersson, Mats wrote:> > > >> -----Original Message----- >> From: xen-users-bounces@lists.xensource.com >> [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of >> Gregory Gee >> Sent: 04 October 2006 14:20 >> To: xen-users@lists.xensource.com >> 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? 2. When and would it be available for consumer boards or only Operton and high end MB? Thanks, Greg _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wed, Oct 04, 2006 at 08:45:20PM -0400, Gregory Gee wrote:> Great, two questions. > > 1. Would this allow a PCI device that is not supported in Linux to be > used in a Windows SVM dom?In theory, yes, assuming Windows does have a driver. The device would be driven directly by windows without any knowledge of dom0. Cheers, Muli _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> -----Original Message----- > From: Gregory Gee [mailto:gregory.gee@sympatico.ca] > Sent: 05 October 2006 01:45 > To: Petersson, Mats > Cc: xen-users@lists.xensource.com > Subject: Re: [Xen-users] AMD''s VT for chipsets > > Petersson, Mats wrote: > > > > > > > >> -----Original Message----- > >> From: xen-users-bounces@lists.xensource.com > >> [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of > >> Gregory Gee > >> Sent: 04 October 2006 14:20 > >> To: xen-users@lists.xensource.com > >> 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@lists.xensource.com http://lists.xensource.com/xen-users