Hello, I''ve been experimenting with VT-d supported PCI-passthrough in Xen for HVM guests, and was wondering if it is possible to create an IOMMU domain for Dom0 as well. I''m not sure if I''m asking the question correctly, but to avoid changing a bare-metal driver for an I/O device to translate system memory addresses used by a DMA engine, would I instead be able to allow the IOMMU to transparently translate addresses just like for guest VMs, but within Dom0? Some searching and reading of the wiki pages on xen.org tells me the answer is "no". But I cannot determine if this is purely because the implementation within the VMM doesn''t exist, or because it is that Dom0 is para-virtualized and thus cannot use VT-d without VT-x. I''m suspecting it is not the latter, as the VTdHowTo wiki page hints PV guests may use VT-d and the Intel manual for VT-d describes OS developers may take advantage of this extension. My immediate interest is more to see if it "can be done" via a hack or something, not necessarily whether it would make sense for Xen to support this in the future. I''m using Xen 4.1.1 and pv-ops linux (not upstream) 2.6.32.40 on an Intel X5660 with a Tylersburg chipset. Thanks! Alex _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
At 2011-06-21 12:17:56，"Alex Merritt" <merritt.alex@gmail.com> wrote:>Hello, > >I've been experimenting with VT-d supported PCI-passthrough in Xen for >HVM guests, and was wondering if it is possible to create an IOMMU >domain for Dom0 as well. I'm not sure if I'm asking the question >correctly, but to avoid changing a bare-metal driver for an I/O device >to translate system memory addresses used by a DMA engine, would I >instead be able to allow the IOMMU to transparently translate >addresses just like for guest VMs, but within Dom0?why put the IOMMU within Dom0? not in the driver domain? Some searching and>reading of the wiki pages on xen.org tells me the answer is "no". But >I cannot determine if this is purely because the implementation within >the VMM doesn't exist, or because it is that Dom0 is para-virtualized >and thus cannot use VT-d without VT-x. I'm suspecting it is not the >latter, as the VTdHowTo wiki page hints PV guests may use VT-d and the >Intel manual for VT-d describes OS developers may take advantage of >this extension. > >My immediate interest is more to see if it "can be done" via a hack or >something, not necessarily whether it would make sense for Xen to >support this in the future. >You should ask this question in xen-dev list.>I'm using Xen 4.1.1 and pv-ops linux (not upstream) 2.6.32.40 on an >Intel X5660 with a Tylersburg chipset. > >Thanks! >Alex > >_______________________________________________ >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, 2011/6/22 sploving <sploving1@163.com>:> > > > At 2011-06-21 12:17:56，"Alex Merritt" <merritt.alex@gmail.com> wrote: > >>Hello, >> >>I''ve been experimenting with VT-d supported PCI-passthrough in Xen for >>HVM guests, and was wondering if it is possible to create an IOMMU >>domain for Dom0 as well. I''m not sure if I''m asking the question >>correctly, but to avoid changing a bare-metal driver for an I/O device >>to translate system memory addresses used by a DMA engine, would I >>instead be able to allow the IOMMU to transparently translate >>addresses just like for guest VMs, but within Dom0? > why put the IOMMU within Dom0? not in the driver domain?I''m using research code, which currently requires the management extension and driver to exist within the same domain. IOMMUs are meant for guest VMs as far as I can tell. They can be used as driver domains, too, but (unless I''m mistaken) cannot use the management interfaces available in Dom0. My driver domain is also Dom0 at the moment.> Some searching and >>reading of the wiki pages on xen.org tells me the answer is "no". But >>I cannot determine if this is purely because the implementation within >>the VMM doesn''t exist, or because it is that Dom0 is para-virtualized >>and thus cannot use VT-d without VT-x. I''m suspecting it is not the >>latter, as the VTdHowTo wiki page hints PV guests may use VT-d and the >>Intel manual for VT-d describes OS developers may take advantage of >>this extension. >> >>My immediate interest is more to see if it "can be done" via a hack or >>something, not necessarily whether it would make sense > for Xen to >>support this in the future. >> > You should ask this question in xen-dev list.Okay, I''ll do that. I''m new to these mailing lists, and wasn''t sure where to start. Thanks.>>I''m using Xen 4.1.1 and pv-ops linux (not upstream) 2.6.32.40 on an >>Intel X5660 with a > Tylersburg chipset. >> >>Thanks! >>Alex >> >>_______________________________________________ >>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
On Wed, Jun 22, 2011 at 1:20 PM, Alex Merritt <merritt.alex@gmail.com> wrote:> Hi, > > 2011/6/22 sploving <sploving1@163.com>: >> >> >> >> At 2011-06-21 12:17:56，"Alex Merritt" <merritt.alex@gmail.com> wrote: >> >>>Hello, >>> >>>I''ve been experimenting with VT-d supported PCI-passthrough in Xen for >>>HVM guests, and was wondering if it is possible to create an IOMMU >>>domain for Dom0 as well. I''m not sure if I''m asking the question >>>correctly, but to avoid changing a bare-metal driver for an I/O device >>>to translate system memory addresses used by a DMA engine, would I >>>instead be able to allow the IOMMU to transparently translate >>>addresses just like for guest VMs, but within Dom0? >> why put the IOMMU within Dom0? not in the driver domain? > > I''m using research code, which currently requires the management > extension and driver to exist within the same domain. IOMMUs are meant > for guest VMs as far as I can tell. They can be used as driver > domains, too, but (unless I''m mistaken) cannot use the management > interfaces available in Dom0. >To me, this research sounds similar to "InDriver: Using In-VM Isolation to Implement Drivers" that is going to be presented at the upcoming Xen Summit see: http://xen.org/community/xensummit.html I could be wrong about the relationship, but it does sound like similar concepts are being explored.> My driver domain is also Dom0 at the moment. > >> Some searching and >>>reading of the wiki pages on xen.org tells me the answer is "no". But >>>I cannot determine if this is purely because the implementation within >>>the VMM doesn''t exist, or because it is that Dom0 is para-virtualized >>>and thus cannot use VT-d without VT-x. I''m suspecting it is not the >>>latter, as the VTdHowTo wiki page hints PV guests may use VT-d and the >>>Intel manual for VT-d describes OS developers may take advantage of >>>this extension. >>> >>>My immediate interest is more to see if it "can be done" via a hack or >>>something, not necessarily whether it would make sense >> for Xen to >>>support this in the future. >>> >> You should ask this question in xen-dev list. > > Okay, I''ll do that. I''m new to these mailing lists, and wasn''t sure > where to start. Thanks. > >>>I''m using Xen 4.1.1 and pv-ops linux (not upstream) 2.6.32.40 on an >>>Intel X5660 with a >> Tylersburg chipset. >>> >>>Thanks! >>>Alex >>> >>>_______________________________________________ >>>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 >-- Todd Deshane http://www.linkedin.com/in/deshantm http://www.xen.org/products/cloudxen.html http://runningxen.com/ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wed, Jun 22, 2011 at 21:48, Todd Deshane <todd.deshane@xen.org> wrote:> On Wed, Jun 22, 2011 at 1:20 PM, Alex Merritt <merritt.alex@gmail.com> wrote: >> Hi, >> >> 2011/6/22 sploving <sploving1@163.com>: >>> >>> >>> >>> At 2011-06-21 12:17:56，"Alex Merritt" <merritt.alex@gmail.com> wrote: >>> >>>>Hello, >>>> >>>>I''ve been experimenting with VT-d supported PCI-passthrough in Xen for >>>>HVM guests, and was wondering if it is possible to create an IOMMU >>>>domain for Dom0 as well. I''m not sure if I''m asking the question >>>>correctly, but to avoid changing a bare-metal driver for an I/O device >>>>to translate system memory addresses used by a DMA engine, would I >>>>instead be able to allow the IOMMU to transparently translate >>>>addresses just like for guest VMs, but within Dom0? >>> why put the IOMMU within Dom0? not in the driver domain? >> >> I''m using research code, which currently requires the management >> extension and driver to exist within the same domain. IOMMUs are meant >> for guest VMs as far as I can tell. They can be used as driver >> domains, too, but (unless I''m mistaken) cannot use the management >> interfaces available in Dom0. >> > > To me, this research sounds similar to "InDriver: Using In-VM > Isolation to Implement Drivers" that is going to be presented at the > upcoming Xen Summit > > see: http://xen.org/community/xensummit.html > > I could be wrong about the relationship, but it does sound like > similar concepts are being explored.Hm, there doesn''t seem to be a link describing the talk/work in more detail. I''m attempting to just give the NVIDIA driver an IOMMU domain in Dom0 for accessing the GPUs within a machine. There''s been a lot of frustration over the years trying to get CUDA to work on Dom0 as well as 3D support. I''m attempting to determine if this is at all possible using VT-d.> > >> My driver domain is also Dom0 at the moment. >> >>> Some searching and >>>>reading of the wiki pages on xen.org tells me the answer is "no". But >>>>I cannot determine if this is purely because the implementation within >>>>the VMM doesn''t exist, or because it is that Dom0 is para-virtualized >>>>and thus cannot use VT-d without VT-x. I''m suspecting it is not the >>>>latter, as the VTdHowTo wiki page hints PV guests may use VT-d and the >>>>Intel manual for VT-d describes OS developers may take advantage of >>>>this extension. >>>> >>>>My immediate interest is more to see if it "can be done" via a hack or >>>>something, not necessarily whether it would make sense >>> for Xen to >>>>support this in the future. >>>> >>> You should ask this question in xen-dev list. >> >> Okay, I''ll do that. I''m new to these mailing lists, and wasn''t sure >> where to start. Thanks. >> >>>>I''m using Xen 4.1.1 and pv-ops linux (not upstream) 2.6.32.40 on an >>>>Intel X5660 with a >>> Tylersburg chipset. >>>> >>>>Thanks! >>>>Alex >>>> >>>>_______________________________________________ >>>>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 >> > > > > -- > Todd Deshane > http://www.linkedin.com/in/deshantm > http://www.xen.org/products/cloudxen.html > http://runningxen.com/ >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users