Mailing List Archive

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

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