'Sloppier' PCI access checks in main tree

'Sloppier' PCI access checks in main tree

[Keir Fraser]

> As I read this, the module loader tried to run the vga bios and failed, as 
> it could not get to the actual BIOS code? That's how it looks to me 
> anyway. 
> 
> I have no idea: has anyone seen option rom access working under Xen? I 
> have not, but I have not tried this recently. The VGA bios ROM is not 
> accessible on my laptop, however. 
> 
> Does Xen currently allow a guest to set enable the option rom access and 
> set the register (0x30 I think) for the option ram base address? 

I've just checked in sloppoer PCI checking for 2.0-testing and
unstable trees. It should help for those drivers that need to monkey
with the base-address config registers (we had previously been
disallowing that). Really, applying any check finer-grained than
"should this domain be allowed to access this device?" is hard as
various drivers need to do all kinds of weird things with the
config-register space.

Hopefully this may help you get further in getting AGP to work on your
system!

 -- Keir


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

RE: 'Sloppier' PCI access checks in main tree

[Ian Pratt]

Stijn,

What kernel are you using? We've all been working on the assumption that
you were using 2.6, but the problem your seeing would be consistent with
using 2.4, which only has support for basic X servers. If you are using
2.4 try disabling the int10/bios/vesa X drivers etc.

[Our /dev/mem under 2.4 doesn't support read/write only mmap.]

Ian

> -----Original Message-----
> From: xen-devel-admin@lists.sourceforge.net 
> [mailto:xen-devel-admin@lists.sourceforge.net] On Behalf Of 
> Keir Fraser
> Sent: 08 January 2005 17:22
> To: Ronald G. Minnich
> Cc: Stijn De Weirdt; xen-devel@lists.sourceforge.net
> Subject: [Xen-devel] 'Sloppier' PCI access checks in main tree
> 
> > As I read this, the module loader tried to run the vga bios 
> and failed, as 
> > it could not get to the actual BIOS code? That's how it looks to me 
> > anyway. 
> > 
> > I have no idea: has anyone seen option rom access working 
> under Xen? I 
> > have not, but I have not tried this recently. The VGA bios 
> ROM is not 
> > accessible on my laptop, however. 
> > 
> > Does Xen currently allow a guest to set enable the option 
> rom access and 
> > set the register (0x30 I think) for the option ram base address? 
> 
> I've just checked in sloppoer PCI checking for 2.0-testing and
> unstable trees. It should help for those drivers that need to monkey
> with the base-address config registers (we had previously been
> disallowing that). Really, applying any check finer-grained than
> "should this domain be allowed to access this device?" is hard as
> various drivers need to do all kinds of weird things with the
> config-register space.
> 
> Hopefully this may help you get further in getting AGP to work on your
> system!
> 
>  -- Keir
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
> 


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: 'Sloppier' PCI access checks in main tree

[Stijn De Weirdt]

sorry missed this email.
i'm using 2.4.28. i'll try today, since i have to recompile my kernel
anyway. reaction times on my system are anything but good (what
performace loss should i expect if i use a file-backed vbd (and what
fs is the most for those). also network seems pretty slow.

stijn


On Sat, 8 Jan 2005 18:42:16 -0000, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> Stijn,
> 
> What kernel are you using? We've all been working on the assumption that
> you were using 2.6, but the problem your seeing would be consistent with
> using 2.4, which only has support for basic X servers. If you are using
> 2.4 try disabling the int10/bios/vesa X drivers etc.
> 
> [Our /dev/mem under 2.4 doesn't support read/write only mmap.]
> 
> Ian
> 
> > -----Original Message-----
> > From: xen-devel-admin@lists.sourceforge.net
> > [mailto:xen-devel-admin@lists.sourceforge.net] On Behalf Of
> > Keir Fraser
> > Sent: 08 January 2005 17:22
> > To: Ronald G. Minnich
> > Cc: Stijn De Weirdt; xen-devel@lists.sourceforge.net
> > Subject: [Xen-devel] 'Sloppier' PCI access checks in main tree
> >
> > > As I read this, the module loader tried to run the vga bios
> > and failed, as
> > > it could not get to the actual BIOS code? That's how it looks to me
> > > anyway.
> > >
> > > I have no idea: has anyone seen option rom access working
> > under Xen? I
> > > have not, but I have not tried this recently. The VGA bios
> > ROM is not
> > > accessible on my laptop, however.
> > >
> > > Does Xen currently allow a guest to set enable the option
> > rom access and
> > > set the register (0x30 I think) for the option ram base address?
> >
> > I've just checked in sloppoer PCI checking for 2.0-testing and
> > unstable trees. It should help for those drivers that need to monkey
> > with the base-address config registers (we had previously been
> > disallowing that). Really, applying any check finer-grained than
> > "should this domain be allowed to access this device?" is hard as
> > various drivers need to do all kinds of weird things with the
> > config-register space.
> >
> > Hopefully this may help you get further in getting AGP to work on your
> > system!
> >
> >  -- Keir
> >
> > 
> > -------------------------------------------------------
> > The SF.Net email is sponsored by: Beat the post-holiday blues
> > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/xen-devel
> >
>


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: 'Sloppier' PCI access checks in main tree

[Ian Pratt]

> sorry missed this email.
> i'm using 2.4.28. i'll try today, since i have to recompile my kernel
> anyway. 

OK, that explains a lot. We might back-port the vm86 and full
/dev/mem support to 2.4, but its not high on the todo
list. Perhaps a volunteer from the audience will step up at this
point ? :-)

> reaction times on my system are anything but good (what
> performace loss should i expect if i use a file-backed vbd (and what
> fs is the most for those). also network seems pretty slow.

The performance loss using file-backed vbd's is typically pretty
small, but I do generally use LVM volumes. Our systems manage to
saturate gigabit Ethernet links no problem, so I'm surprised
you're seeing network slow downs. There have been reports about
IRQ problems causing slow downs on some systems, and we're
investigating.

Ian


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: 'Sloppier' PCI access checks in main tree

[Stijn De Weirdt]

i give a snapshot of dmesg of a vm:
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
hda: C/H/S=0/0/0 from BIOS ignored
hdb: C/H/S=0/0/0 from BIOS ignored

output of working system (dmesg from dom0 is very similar and works normal)
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH5: IDE controller at PCI slot 00:1f.1
PCI: Enabling device 00:1f.1 (0005 -> 0007)
PCI: Found IRQ 10 for device 00:1f.1
PCI: Sharing IRQ 10 with 00:1d.2
PCI: Sharing IRQ 10 with 00:1f.2
ICH5: chipset revision 2
ICH5: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: Maxtor 6Y080L0, ATA DISK drive
blk: queue c043ea80, I/O limit 4095Mb (mask 0xffffffff)
hdc: SONY CD-RW CRX320E, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: attached ide-disk driver.
hda: host protected area => 1
hda: 160086528 sectors (81964 MB) w/2048KiB Cache, CHS=158816/16/63, UDMA(100)
ide-floppy driver 0.99.newide
Partition check:
 /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 >

so i think that the correct controller is found in dom0, but in a vm
(using same xen0-kernel)
performance is bad (about the network, transfer speeds are high, but a
ssh login takes about 40 sec)

stijn

On Wed, 12 Jan 2005 08:39:21 +0000, Ian Pratt <Ian.Pratt@cl.cam.ac.uk> wrote:
> > sorry missed this email.
> > i'm using 2.4.28. i'll try today, since i have to recompile my kernel
> > anyway.
> 
> OK, that explains a lot. We might back-port the vm86 and full
> /dev/mem support to 2.4, but its not high on the todo
> list. Perhaps a volunteer from the audience will step up at this
> point ? :-)
> 
> > reaction times on my system are anything but good (what
> > performace loss should i expect if i use a file-backed vbd (and what
> > fs is the most for those). also network seems pretty slow.
> 
> The performance loss using file-backed vbd's is typically pretty
> small, but I do generally use LVM volumes. Our systems manage to
> saturate gigabit Ethernet links no problem, so I'm surprised
> you're seeing network slow downs. There have been reports about
> IRQ problems causing slow downs on some systems, and we're
> investigating.
> 
> Ian
>


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: 'Sloppier' PCI access checks in main tree

[Ian Pratt]

> performance is bad (about the network, transfer speeds are high, but a
> ssh login takes about 40 sec)

I'll bet that's just an ssh X forwarding issue.

Try 'ssh -x user@machine'.

Ian


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: 'Sloppier' PCI access checks in main tree

[Stijn De Weirdt]

hi ian,

i have some more info about the speeding problems 
this is from an installation log 

05/01/13 15:14:03:    /usr/sbin/usermod -d /home/alice001 -g alice -u
10417 -c mapped user for alice alice001
05/01/13 15:14:03:    /usr/sbin/usermod -d /home/alice002 -g alice -u
10418 -c mapped user for alice alice002
05/01/13 15:14:03:    /usr/sbin/usermod -d /home/alice003 -g alice -u
10420 -c mapped user for alice alice003
05/01/13 15:14:03:    /usr/sbin/usermod -d /home/alice004 -g alice -u
10454 -c mapped user for alice alice004
05/01/13 15:14:03:    /usr/sbin/usermod -d /home/alice005 -g alice -u
10472 -c mapped user for alice alice005
05/01/13 15:14:03:    /usr/sbin/usermod -d /home/alice006 -g alice -u
10511 -c mapped user for alice alice006
05/01/13 15:14:03:    /usr/sbin/usermod -d /home/alice007 -g alice -u
10562 -c mapped user for alice alice007
05/01/13 15:14:03:    /usr/sbin/useradd -d /home/alice008 -g alice -u
10567 -c mapped user for alice alice008
05/01/13 15:17:03:    /usr/sbin/useradd -d /home/alice009 -g alice -u
10618 -c mapped user for alice alice009
05/01/13 15:20:04:    /usr/sbin/useradd -d /home/alice010 -g alice -u
10625 -c mapped user for alice alice010

do you notice the slowdown? is there a way i can monitor the
cpu/mem/ps ax on this vm from dom0 to get more info. the script only
does what it's supposed to do (namely useradd, but that can't give
those problems)

(and what is the correct policy for the /dev/rtc? just disable in
kernel? or only in the vm's, but leave it on in dom0?)

stijn

On Wed, 12 Jan 2005 18:18:37 +0000, Ian Pratt <Ian.Pratt@cl.cam.ac.uk> wrote:
> 
> > performance is bad (about the network, transfer speeds are high, but a
> > ssh login takes about 40 sec)
> 
> I'll bet that's just an ssh X forwarding issue.
> 
> Try 'ssh -x user@machine'.
> 
> Ian
>


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt