Hi, I seem to be undable to delete MTRRs in domain0: root@tpkurt:~ [0]# cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=0 reg01: base=0x1ff80000 ( 511MB), size= 512KB: uncachable, count=0 reg02: base=0xe0000000 (3584MB), size= 32MB: write-combining, count=0 reg03: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=0 root@tpkurt:~ [0]# echo "disable=1" /proc/mtrr disable=1 /proc/mtrr root@tpkurt:~ [0]# echo "disable=1" >/proc/mtrr root@tpkurt:~ [1]# cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=0 reg01: base=0x1ff80000 ( 511MB), size= 512KB: uncachable, count=0 reg02: base=0xe0000000 (3584MB), size= 32MB: write-combining, count=0 reg03: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=0 Isn''t this supposed to work? -- Kurt Garloff <kurt@garloff.de> [Koeln, DE] Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL] Linux: SUSE Labs (Director) <garloff@suse.de> [Novell Inc]
On 24 Mar 2005, at 18:06, Kurt Garloff wrote:> I seem to be undable to delete MTRRs in domain0: > > root@tpkurt:~ [0]# cat /proc/mtrr > reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=0 > reg01: base=0x1ff80000 ( 511MB), size= 512KB: uncachable, count=0 > reg02: base=0xe0000000 (3584MB), size= 32MB: write-combining, count=0 > reg03: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=0 > root@tpkurt:~ [0]# echo "disable=1" /proc/mtrr > disable=1 /proc/mtrr > root@tpkurt:~ [0]# echo "disable=1" >/proc/mtrr > root@tpkurt:~ [1]# cat /proc/mtrr > reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=0 > reg01: base=0x1ff80000 ( 511MB), size= 512KB: uncachable, count=0 > reg02: base=0xe0000000 (3584MB), size= 32MB: write-combining, count=0 > reg03: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=0 > > Isn''t this supposed to work?It''s been hacked just enough to get X working, but the /proc semantics haven''t been given much thought. The problem is that reading /proc/mtrr tells you what the real physical MTRRs contain, but these registers weren''t initialised by domain0 but by Xen, during SMP bootstrap. So when you attempt to delete them you will probably find error messages in /var/log/messages saying ''reg1 has count=0''. There are a few possible fixes, one being to let domain0 get staright at the MTRRs after it has booted, but this needs great care -- the registers have to be carefully synchronised across all physical CPUs to avoid memory deadlocks. Better might be to have a low-level stateless interface exported by Xen, and have domain0 read the MTRR state during boot and set its refcnt to one for each MTRR that is initialised and in use. -- Keir ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Hi Keir, On Thu, Mar 24, 2005 at 06:26:44PM +0000, Keir Fraser wrote:> It''s been hacked just enough to get X working, but the /proc semantics > haven''t been given much thought. The problem is that reading /proc/mtrr > tells you what the real physical MTRRs contain, but these registers > weren''t initialised by domain0 but by Xen, during SMP bootstrap. So > when you attempt to delete them you will probably find error messages > in /var/log/messages saying ''reg1 has count=0''.I thought the MTRRs have been set by the BIOS, not Xen. The MTRRs are not set to my satisfaction, that''s why I''d like to change them.> There are a few possible fixes, one being to let domain0 get staright > at the MTRRs after it has booted, but this needs great care -- > the registers have to be carefully synchronised across all physical > CPUs to avoid memory deadlocks.Obviously, Linux has code to do that -- under Xen it unfortunately only sees a subset of the CPUs, though. Regards, -- Kurt Garloff <kurt@garloff.de> [Koeln, DE] Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL] Linux: SUSE Labs (Director) <garloff@suse.de> [Novell Inc]
> I thought the MTRRs have been set by the BIOS, not Xen.Xen propagates the CPU0 MTRR values to all other CPUs. Not all BIOSes do that properly. Linux does the same, when it is booted natively.> The MTRRs are not set to my satisfaction, that''s why I''d like to change > them.Hmmm... can you try changing init_table() in arch/xen/i386/kernel/cpu/mtrr/main.c to initialise the usage_table counts to 1 instead of 0? I think that''ll fix it for you and matches how native Linux initialises the table.> Obviously, Linux has code to do that -- under Xen it unfortunately > only sees a subset of the CPUs, though.You need to lock out all other CPU activity while you reprogram MTRRs across all CPUs. Obviously Linux cannot do that unaided if Xen is running underneath it. I think the current approach is the correct one, but I was probably trying to be too clever when defining the interface to Xen -- we''ll probably end up dumbing it down, and only allow domain0 to do MTRR updates. We can always define an interface thru domain0 for other driver domains to declare memory types if we feel the need. If you can check that modifying initialisation of usage_table[] fixes your problem, I''ll do a cleanup and simplification of the MTRR code. -- Keir ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel