Hello All, I want to run ''real device drivers'' I mean native drivers (ofcourse recompiled for xen) as part of the two guests (Linux OS). These drivers will be accessing seperate devices and will not be shared by guests. Do you think this configuration is possible ? I am referring to a system with just PV and no HVM. My understanding of ''dmo0'' or the driver domain is that only those devices/device-drivers which need to be shared between guest OS have to run in the driver domain but otherwise they can run as part of the unprivlidged guest domain. The other reason is that xen wants to have just one set of drivers for all guest OS. I just want avoid writing front end and back end driver pairs for custom device drivers and run as it is in their respective domains. Regards, Phani _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2007-12-12 at 20:39 -0800, Phani Babu Giddi wrote:> Hello All, > > I want to run ''real device drivers'' I mean native drivers (ofcourse > recompiled for xen) as part of the two guests (Linux OS). These > drivers will be accessing seperate devices and will not be shared by > guests. Do you think this configuration is possible ? I am referring > to a system with just PV and no HVM.Sounds like you need the PV PCI pass-through functionality (pcifront/pciback). This will allow you to assign a PCI device to a domU instead of dom0. http://www.wlug.org.nz/XenPciPassthrough looks like a reasonable doc, you should also search the list archives. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Phani Babu Giddi
2007-Dec-13 15:08 UTC
Re: [Xen-devel] run real drivers in differnt domains
Hi Ian, Looks like this pass-through will work for devices on the PCI bus. But what about devices that are not on the PCI bus. I was going through one of the threads which talks about differences between xen 1.2 and 2.0 drivers. Where it mentions it possible to have such drivers. Is this possible with Xen 3.0also ? Regards, Phani Re: Xen 1.2 vs 2.0 device drivers *Subject*: Re: Xen 1.2 vs 2.0 device drivers *List-id*: List for Xen developers<file:///C:/Users/phani/Documents/Re%20Xen%201_2%20vs%202_0%20device%20drivers.mht#>< xen-devel.lists.sourceforge.net>>*Hi, looking at the 2004-xen-ols-pdf papers''s xen 2.0 Architecture fig * >*vs. the 1.2 fig, what is the* >*differences between the device drivers<file:///C:/Users/phani/Documents/Re%20Xen%201_2%20vs%202_0%20device%20drivers.mht#>? It seems like the drivers for *>*1.2 is ported to function in the* >*paravirtual environment, but what is the deal with the 2.0 Front-end * >*and Vanilla device drivers?* >** >*Fig 2.0 also has three red arrows, one from the 2.4 kernel to the HW * >*layer and two from the domain<file:///C:/Users/phani/Documents/Re%20Xen%201_2%20vs%202_0%20device%20drivers.mht#> 0. What does*>*this mean in contrast to fig. 1.2 ?*In 1.2, the "real" device drivers were part of Xen. Device drivers in guest OSes were ''virtual'' device drivers that actually just talked to Xen to get anything done. In 2.0, the "real" device drivers run in one or more privileged guest OSes. Xen only deals with the timer (APIC) hardware <file:///C:/Users/phani/Documents/Re%20Xen%201_2%20vs%202_0%20device%20drivers.mht#>, the low-level parts of interrupt dispatch, and some parts of the device probing functionality. Essentially linux device drivers (or BSD ones for that matter) can run unmodified in a guest OS which, among other things, gives us a lot more device support. Many devices (especially network and disk) are shared between guest OSes but there is only ever one "real" device driver. To make this sharing work, a privileged guest also includes a "back-end" driver for every real hardware device. All unprivileged guests wishing to share the device include a "front-end" driver. Both of these "drivers" are actually virtual; they do not directly talk to the hardware. Instead they are connected together using a device channel -- essentially a general means of communication between different virtual machines <file:///C:/Users/phani/Documents/Re%20Xen%201_2%20vs%202_0%20device%20drivers.mht#>. So if e.g. an unprivileged dom1 wants to share a real e1000 network card, the setup might be: dom1 front-end driver -> dom0 back-end driver -> dom0 e1000 driver. The last driver is a "vanilla" linux device driver meaning that it''s source code <file:///C:/Users/phani/Documents/Re%20Xen%201_2%20vs%202_0%20device%20drivers.mht#> is identical to that in the regular linux kernel. The front-end and back-end drivers are new. The lines in the figure connecting domains together represent the device channels that allow domains to talk to one another. The lines in the figure going from a domain ''through'' xen represent the way in which a suitably privileged domain can be given direct access to [a subset of] the real hardware. You may find the our "Reconstructing I/O" paper gives a clearer description of all of this. cheers, S. On Dec 13, 2007 1:43 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:> > On Wed, 2007-12-12 at 20:39 -0800, Phani Babu Giddi wrote: > > Hello All, > > > > I want to run ''real device drivers'' I mean native drivers (ofcourse > > recompiled for xen) as part of the two guests (Linux OS). These > > drivers will be accessing seperate devices and will not be shared by > > guests. Do you think this configuration is possible ? I am referring > > to a system with just PV and no HVM. > > Sounds like you need the PV PCI pass-through functionality > (pcifront/pciback). This will allow you to assign a PCI device to a domU > instead of dom0. > > http://www.wlug.org.nz/XenPciPassthrough looks like a reasonable doc, > you should also search the list archives. > > Ian. > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2007-12-13 at 07:08 -0800, Phani Babu Giddi wrote:> Hi Ian, > > Looks like this pass-through will work for devices on the PCI bus. But > what about devices that are not on the PCI bus. I was going through > one of the threads which talks about differences between xen 1.2 and > 2.0 drivers. Where it mentions it possible to have such drivers. Is > this possible with Xen 3.0 also ?I don''t think so, your choices are basically PV front/back virtual devices (like we have for net, block and a couple of others) or PCI passthrough of a physical PCI device. What type of device are you dealing with? Ian.> > Regards, > Phani > Re: Xen 1.2 vs 2.0 device drivers > > Subject: > Re: Xen 1.2 vs 2.0 device drivers > List-id: > List for Xen developers > <xen-devel.lists.sourceforge.net> > >Hi, looking at the 2004-xen-ols-pdf papers''s xen 2.0 Architecture fig > >vs. the 1.2 fig, what is the > >differences between the > > device drivers? It seems like the drivers for > >1.2 is ported to function in the > >paravirtual environment, but what is the deal with the 2.0 Front-end > >and Vanilla device drivers? > > > >Fig 2.0 also has three red arrows, one from the 2.4 kernel to the HW > >layer and two from the > > domain 0. What does > >this mean in contrast to fig. 1.2 ? > > In 1.2, the "real" device drivers were part of Xen. Device drivers in > guest OSes were ''virtual'' device drivers that actually just talked to > Xen to get anything done. > > In 2.0, the "real" device drivers run in one or more privileged guest > OSes. Xen only deals with the timer (APIC) > > hardware, the low-level > parts of interrupt dispatch, and some parts of the device probing > functionality. Essentially linux device drivers (or BSD ones for that > matter) can run unmodified in a guest OS which, among other things, gives > us a lot more device support. > > Many devices (especially network and disk) are shared between guest OSes > but there is only ever one "real" device driver. To make this sharing > work, a privileged guest also includes a "back-end" driver for every real > hardware device. All unprivileged guests wishing to share the device > include a "front-end" driver. Both of these "drivers" are actually virtual; > they do not directly talk to the hardware. Instead they are connected > together using a device channel -- essentially a general means of communication > between different > > virtual machines > . > > So if e.g. an unprivileged dom1 wants to share a real e1000 network card, > the setup might be: > > dom1 front-end driver -> dom0 back-end driver -> dom0 e1000 driver. > > The last driver is a "vanilla" linux device driver meaning that it''s > > > source code is identical to that in the regular linux kernel. The front-end > and back-end drivers are new. > > The lines in the figure connecting domains together represent the > device channels that allow domains to talk to one another. > > The lines in the figure going from a domain ''through'' xen represent the > way in which a suitably privileged domain can be given direct access to > [a subset of] the real hardware. > > > You may find the our "Reconstructing I/O" paper gives a clearer description > of all of this. > > > cheers, > > S. > > > > > > On Dec 13, 2007 1:43 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Wed, 2007-12-12 at 20:39 -0800, Phani Babu Giddi wrote: > > Hello All, > > > > I want to run ''real device drivers'' I mean native drivers > (ofcourse > > recompiled for xen) as part of the two guests (Linux OS). > These > > drivers will be accessing seperate devices and will not be > shared by > > guests. Do you think this configuration is possible ? I am > referring > > to a system with just PV and no HVM. > > > Sounds like you need the PV PCI pass-through functionality > (pcifront/pciback). This will allow you to assign a PCI device > to a domU > instead of dom0. > > http://www.wlug.org.nz/XenPciPassthrough looks like a > reasonable doc, > you should also search the list archives. > > Ian. > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Williamson
2007-Dec-13 17:10 UTC
Re: [Xen-devel] run real drivers in differnt domains
> > Looks like this pass-through will work for devices on the PCI bus. But > > what about devices that are not on the PCI bus. I was going through > > one of the threads which talks about differences between xen 1.2 and > > 2.0 drivers. Where it mentions it possible to have such drivers. Is > > this possible with Xen 3.0 also ? > > I don''t think so, your choices are basically PV front/back virtual > devices (like we have for net, block and a couple of others) or PCI > passthrough of a physical PCI device.I think it''s possible to get very simple legacy devices passed through, for instance serial ports. There is syntax in the config files to allow individual IRQs, MMIO regions and IO port ranges to be granted, I think. Cheers, Mark> What type of device are you dealing with? > > Ian. > > > Regards, > > Phani > > Re: Xen 1.2 vs 2.0 device drivers > > > > Subject: > > Re: Xen 1.2 vs 2.0 device drivers > > List-id: > > List for Xen developers > > <xen-devel.lists.sourceforge.net> > > > > >Hi, looking at the 2004-xen-ols-pdf papers''s xen 2.0 Architecture fig > > >vs. the 1.2 fig, what is the > > >differences between the > > > > device drivers? It seems like the drivers for > > > > >1.2 is ported to function in the > > >paravirtual environment, but what is the deal with the 2.0 Front-end > > >and Vanilla device drivers? > > > > > >Fig 2.0 also has three red arrows, one from the 2.4 kernel to the HW > > >layer and two from the > > > > domain 0. What does > > > > >this mean in contrast to fig. 1.2 ? > > > > In 1.2, the "real" device drivers were part of Xen. Device drivers in > > guest OSes were ''virtual'' device drivers that actually just talked to > > Xen to get anything done. > > > > In 2.0, the "real" device drivers run in one or more privileged guest > > OSes. Xen only deals with the timer (APIC) > > > > hardware, the low-level > > parts of interrupt dispatch, and some parts of the device probing > > functionality. Essentially linux device drivers (or BSD ones for that > > matter) can run unmodified in a guest OS which, among other things, gives > > us a lot more device support. > > > > Many devices (especially network and disk) are shared between guest OSes > > but there is only ever one "real" device driver. To make this sharing > > work, a privileged guest also includes a "back-end" driver for every real > > hardware device. All unprivileged guests wishing to share the device > > include a "front-end" driver. Both of these "drivers" are actually > > virtual; they do not directly talk to the hardware. Instead they are > > connected together using a device channel -- essentially a general means > > of communication between different > > > > virtual machines > > . > > > > So if e.g. an unprivileged dom1 wants to share a real e1000 network card, > > the setup might be: > > > > dom1 front-end driver -> dom0 back-end driver -> dom0 e1000 driver. > > > > The last driver is a "vanilla" linux device driver meaning that it''s > > > > > > source code is identical to that in the regular linux kernel. The > > front-end and back-end drivers are new. > > > > The lines in the figure connecting domains together represent the > > device channels that allow domains to talk to one another. > > > > The lines in the figure going from a domain ''through'' xen represent the > > way in which a suitably privileged domain can be given direct access to > > [a subset of] the real hardware. > > > > > > You may find the our "Reconstructing I/O" paper gives a clearer > > description of all of this. > > > > > > cheers, > > > > S. > > > > > > > > > > > > On Dec 13, 2007 1:43 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > > > On Wed, 2007-12-12 at 20:39 -0800, Phani Babu Giddi wrote: > > > Hello All, > > > > > > I want to run ''real device drivers'' I mean native drivers > > > > (ofcourse > > > > > recompiled for xen) as part of the two guests (Linux OS). > > > > These > > > > > drivers will be accessing seperate devices and will not be > > > > shared by > > > > > guests. Do you think this configuration is possible ? I am > > > > referring > > > > > to a system with just PV and no HVM. > > > > Sounds like you need the PV PCI pass-through functionality > > (pcifront/pciback). This will allow you to assign a PCI device > > to a domU > > instead of dom0. > > > > http://www.wlug.org.nz/XenPciPassthrough looks like a > > reasonable doc, > > you should also search the list archives. > > > > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Re-adding xen-devel. On Thu, 2007-12-13 at 09:55 -0800, Phani Babu Giddi wrote:> Hi Ian, > > The device that I want to interface are custome FPGA''s connected using > different busses it could be LPC or else SMbus or I2c.LPC might be doable by passing the I/O ports through to the guest as Mark described or if the SMbus/I2C controller is a PCI device you might be able to pass that through.> So has this feature been taken off in Xen 3.0 i.e to run native > drivers in Gues OS.Apart from PCI devices, pretty much, yes. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel