Do we have a list of drivers that have been validated to work in a Xen environment. Equally important would be the list of drivers that we know have some issues working in a Xen environment. Thanks, K. Y ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> Do we have a list of drivers that have been validated to work in a Xen > environment. Equally important would be the list of drivers that we know > have some issues working in a Xen environment.Pretty much all the drivers built into the current dom0 config have been booted on some machine and found to work. There have been some reports of a strange issue involving the e100 driver and the debian startup scripts, but we haven''t reproduced locally and there seems to be a good workaround. If someone sends us an oops message its probably trivial to fix. I''ve actually been impressed (amazed!) at how few problems we''ve found with Linux drivers running over Xen. We''re certainly rather stricter than what''s possible to get away with on native x86, but I guess the ubiquity of PCI has meant that most popular drivers have been debugged on sparc/alpha/ia64/ppc and have had the bogus assumptions beaten out of them. The only hardware drivers known to have problems are agpgart and drm. The patch directory contains a few patches that fix some obvious bugs, but more work is required. The xfree86 server VESA driver doesn''t work due to it requiring support for vm86 mode. Stephan is looking into this. The other driver that I know we have an issue with is the cisco linux-iscsi initiator on 2.4. There''s a workaround by setting hacking the driver to set DISABLE_CLUSTERING. The 2.6 iscsi driver works fine. Ian ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Related to this, I wrote a little script that disassembles the kernel and drivers, looking for privileged instructions. (The BUG macro must first be modified to avoid many false positives, however.) It turned up a problem in the file linux-2.6.8.1/drivers/mtd/maps/nettel.c. I''ve attached a patch -- can we put this in the patches directory? I also noticed a number of scary things in the kernel itself (moves to/from CR4, various CLI/STI pairs, maybe some others but I forget ATM) but it appears that these are avoided at runtime. Some of these could and probably should be cleaned up, though, since they exist in the arch/xen tree. I''ll come back with some more details on this. Thanks.>>>Ian Pratt <Ian.Pratt@cl.cam.ac.uk> 10/25/04 2:11 pm >>> >Do we have a list of drivers that have been validated to work in a Xen >environment. Equally important would be the list of drivers that weknow>have some issues working in a Xen environment.Pretty much all the drivers built into the current dom0 config have been booted on some machine and found to work. There have been some reports of a strange issue involving the e100 driver and the debian startup scripts, but we haven''t reproduced locally and there seems to be a good workaround. If someone sends us an oops message its probably trivial to fix. I''ve actually been impressed (amazed!) at how few problems we''ve found with Linux drivers running over Xen. We''re certainly rather stricter than what''s possible to get away with on native x86, but I guess the ubiquity of PCI has meant that most popular drivers have been debugged on sparc/alpha/ia64/ppc and have had the bogus assumptions beaten out of them. The only hardware drivers known to have problems are agpgart and drm. The patch directory contains a few patches that fix some obvious bugs, but more work is required. The xfree86 server VESA driver doesn''t work due to it requiring support for vm86 mode. Stephan is looking into this. The other driver that I know we have an issue with is the cisco linux-iscsi initiator on 2.4. There''s a workaround by setting hacking the driver to set DISABLE_CLUSTERING. The 2.6 iscsi driver works fine. Ian ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> Related to this, I wrote a little script that disassembles the kernel > and drivers, looking for privileged instructions. (The BUG macro must > first be modified to avoid many false positives, however.)That''s certainly a useful exercise.> It turned up a problem in the file > linux-2.6.8.1/drivers/mtd/maps/nettel.c. I''ve attached a patch -- can > we put this in the patches directory?Definitely -- remind me if it doesn''t appear soon.> I also noticed a number of scary things in the kernel itself (moves > to/from CR4, various CLI/STI pairs, maybe some others but I forget ATM) > but it appears that these are avoided at runtime. Some of these could > and probably should be cleaned up, though, since they exist in the > arch/xen tree. I''ll come back with some more details on this.Because of the ''minimum changes'' approach we''ve taken to the 2.6 port there''s a certain amount of code that''s compiled in but never used. Hopefully these instructions will be on those paths, but it would be nice to have a list of them to verify. If/when we''re in the mainstream kernel tree we can take a more aggressive approach about cleaning things up. Ian ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Mon, 25 Oct 2004, Ian Pratt wrote:> The only hardware drivers known to have problems are agpgart and > drm.And a bunch of old ISA drivers that need isa_virt_to_bus. Chances are the only one people will notice here is the floppy driver - but I haven''t heard any complaints yet, so ;) -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan ------------------------------------------------------- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry''s leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> On Mon, 25 Oct 2004, Ian Pratt wrote: > > > The only hardware drivers known to have problems are agpgart and > > drm. > > And a bunch of old ISA drivers that need isa_virt_to_bus. > Chances are the only one people will notice here is the > floppy driver - but I haven''t heard any complaints yet, so ;)Yes, good point. I guess this could cause problems for some older PCMCIA devices too. However, since we now give dom0 a direct map of the bottom 1MB of memory (starting at PAGE_OFFSET) it may be trivial to implement isa_virt_to_bus e.g. as virt_to_phys as per normal i386. Anyone still got a floppy drive to try this out on? ;-) Ian ------------------------------------------------------- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry''s leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > On Mon, 25 Oct 2004, Ian Pratt wrote: > > > > > The only hardware drivers known to have problems are agpgart and > > > drm. > > > > And a bunch of old ISA drivers that need isa_virt_to_bus. > > Chances are the only one people will notice here is the > > floppy driver - but I haven''t heard any complaints yet, so ;) > > Yes, good point. I guess this could cause problems for some older > PCMCIA devices too. > > However, since we now give dom0 a direct map of the bottom 1MB of > memory (starting at PAGE_OFFSET) it may be trivial to implement > isa_virt_to_bus e.g. as virt_to_phys as per normal i386. > > Anyone still got a floppy drive to try this out on? ;-)The mapping of ISA space is actually in the fixmap region. Furthermore, it is only the lowest 1MB of memory -- but I think the isa_* macros can be used for the lowest 16MB. -- Keir ------------------------------------------------------- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry''s leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Rik van Riel <riel <at> redhat.com> writes:> > On Mon, 25 Oct 2004, Ian Pratt wrote: > > > The only hardware drivers known to have problems are agpgart and > > drm. > > And a bunch of old ISA drivers that need isa_virt_to_bus. > Chances are the only one people will notice here is the > floppy driver - but I haven''t heard any complaints yet, so ;) >I''m trying to compile a 2.6.9 dom0 kernel with 2.0 patches using a kernel configuration as close as possible to debian''s 2.6.8-1-k7 kernel. Along the way, I get a lot of isa_virt_to_bus_is_UNSUPPORTED errors similar to the below: CC [M] drivers/net/lance.o drivers/net/lance.c: In function `lance_probe1'': drivers/net/lance.c:564: error: `isa_virt_to_bus_is_UNSUPPORTED'' undeclared (fir st use in this function) drivers/net/lance.c:564: error: (Each undeclared identifier is reported only onc e drivers/net/lance.c:564: error: for each function it appears in.) drivers/net/lance.c: In function `lance_open'': drivers/net/lance.c:780: error: `isa_virt_to_bus_is_UNSUPPORTED'' undeclared (fir st use in this function) drivers/net/lance.c: In function `lance_init_ring'': drivers/net/lance.c:875: error: `isa_virt_to_bus_is_UNSUPPORTED'' undeclared (fir st use in this function) So I guess that hits the problem that Rik mentioned above. I also had this problem for synclinc.c and floppy.h, so I rgrep''ed for isa_virt_to_bus in the kernel tree : drivers/net/lance.c drivers/net/cs89x0.c drivers/net/ni65.c drivers/net/3c505.c drivers/net/3c515.c drivers/net/3c527.c drivers/char/esp.c drivers/char/tpqic02.c drivers/char/synclink.c drivers/scsi/mca_53c9x.c drivers/scsi/wd7000.c drivers/scsi/ibmmca.c drivers/scsi/aha1542.c drivers/scsi/ultrastor.c drivers/block/ps2esdi.c include/asm/io.h include/asm/floppy.h include/.asm-ignore/asm/io.h include/.asm-ignore/asm-i386/io.h include/asm-x86_64/io.h include/asm-x86_64/floppy.h include/asm-i386/io.h include/asm-i386/floppy.h include/asm-mips/io.h include/asm-arm/io.h include/asm-xen/asm/io.h include/asm-xen/asm-i386/io.h So I guess these are the specific ones to watch out for. Is it safe for me to just remove each of the above (lance, cs89x0, floppy, etc) from the kernel configuration? Also, lots of things include <asm/io.h> - is that safe? Ian mentioned that it may be trivial to implement isa_virt_to_bus; if you do, I have floppies to test it out on ;) ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> So I guess these are the specific ones to watch out for. Is it safe for me to > just remove each of the above (lance, cs89x0, floppy, etc) from the kernel > configuration? Also, lots of things include <asm/io.h> - is that safe? > > Ian mentioned that it may be trivial to implement isa_virt_to_bus; if you do, I > have floppies to test it out on ;)asm/io.h is in general safe, but the drivers that use isa_virt_to_bus are *not*. Implementing isa_virt_to_bus() is currently not possible -- the issue is that ISA devices can only DMA to/from the lowest 16MB of physical memory. In native Linux the ZONE_DMA allocator region contains suitable memory -- drivers can allocate from there then program the ISA DMA controller with addresses from isa_virt_to_bus(). On XenLinux the ZONE_DMA is filled with the lowest 16MB of *pseudophysical* memory, not real physical. This means that isa_virt_to_bus() on an address allocated with, e.g. the GFP_DMA flag, is a nonsense. The resulting address is almost certainly above 16MB in real physical memory -- also drivers will assume that buffers alloc''ed with GFP_DMA are contiguous in real physical memory, but XenLinux does not guarantee this. So --- the drivers you list are basically non-starters for XenLinux. The floppy driver can probably be salvaged, however. What I''ll do is customise floppy.h for Xen so that it always uses ''virtual DMA'' mode (basically PIO). It does this for memory >1MB by default anyway, so that code path should be well tested and cause no problems. -- Keir PS. We have a similar problem for any device that has a DMA limit !architectural physmem limit. We need to audit checks in the kernel that they are doing the comparison of DMA buffers against the device limit in real physical addresses, not pseudophysical. We also probably need to add a list of unsupported devices to a README or a FAQ. ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel