Improved Memory Security For Radeon DRM

[phoronix]

Phoronix: Improved Memory Security For Radeon DRM

Yesterday the TTM memory manager and Radeon kernel mode-setting code entered the mainline Linux kernel Git tree, which means it will be part of the next Linux 2.6.31 kernel release. In the 2.6.31 series this new Radeon driver will be marked as "staging" as there is still some work left to be accomplished and further testing needs to be done with this driver and different Radeon graphics cards...

http://www.phoronix.com/vr.php?view=NzMzMw

[bugmenot]

Dear Phoronix,

Can you please link to some mail archive other than the abomination that is sourceforge? Much appreciates - an anonymous user.

Personally, I find gmane to be much more readable. and faster.

[susikala]

Seconded. Gmane is so much easier to read, sourceforge could only be the worst choice for a link.

Edit: adding the link:
http://article.gmane.org/gmane.comp.video.dri.devel/36435

[Ant P.]

Couldn't be bothered looking for it in gmane, but here you go:
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg40780.html

[Pfanne]

when can we expect kms for r600-r700 to enter the kernel?

[bridgman]

The pacing item here is memory management for 6xx-7xx. We may need to release some additional HW info in order to finish memory management (specifically interrupts), not sure but looking into it.

It's probably safe to say "either 2.6.31 or 2.6.32" but hard to be more precise.

[kernelOfTruth]

it's very subjective which parts should be developed earlier:

for me it's definitely not KMS ;)

any info when additional power management support or improvements will be added to the xf86-video-ati or radeonhd driver ?

currently my box is getting warmer several degrees (centigrade) which also implies higher power consumption compared to fglrx/catalyst, for several people there's also the problem of fast spinning fans which is unacceptable :eek:

I know that 3D surely still takes a while for R600 or R700 but at least proper power management should be there

(even without DRI it's already faster than fglrx during 2D operations :) )

thanks

[bridgman]

it's very subjective which parts should be developed earlier: for me it's definitely not KMS ;)

any info when additional power management support or improvements will be added to the xf86-video-ati or radeonhd driver

Here's the problem - additional power management support really needs to go in the kernel on top of KMS. The next real step in power management is dynamic adjustment of clocks and voltage, and that requires hooks into both modesetting and 2D/3D acceleration. The only place all that information comes together is in the kernel with KMS running, so that's where the power management code needs to go.

It is certainly possible to build additional protocols to pass modesetting info from a userspace driver down to the kernel, but since KMS is already in progress none of the devs thing it's worth implementing a throw-away solution in userspace.

currently my box is getting warmer several degrees (centigrade) which also implies higher power consumption compared to fglrx/catalyst, for several people there's also the problem of fast spinning fans which is unacceptable :eek:

Are you already using ForceLowPowerMode and related options ?

[smitty3268]

Have you tried the power management stuff in xf86-video-ati master and it isn't good enough?

I think the kernel MM is important to do ASAP because almost everything else they're doing right now relies on it working first. Power management can get tacked on at any time.

[Louise]

3% ? That's nothing. 100% that's a big deal.

Actually I wonder where we are going in graphics. It is easy to think of things to use CPU power for, but what happens when we have GPU's that can do Lord of the Rings type of graphics real time?

Physics doesn't scale like graphics does. If you do physics that effect game play, you have to simulate it all the time. E.g. it would be bad if you knocked some boxes over, and they land in one way if you look at then, and if you turn around, while they fall, they land in a different way :)

So I think we will get GPU's that can do very close LotR movie quality in the next generation of GPU's.

I say "Lord of the Rings movie quality is enough for anyone", so let's just burn some percentages off on security :D

[kernelOfTruth]

Here's the problem - additional power management support really needs to go in the kernel on top of KMS. The next real step in power management is dynamic adjustment of clocks and voltage, and that requires hooks into both modesetting and 2D/3D acceleration. The only place all that information comes together is in the kernel with KMS running, so that's where the power management code needs to go.

It is certainly possible to build additional protocols to pass modesetting info from a userspace driver down to the kernel, but since KMS is already in progress none of the devs thing it's worth implementing a throw-away solution in userspace.

I also realized this a few minutes after having written that post - so I guess both (KMS and better power management) will come soon

thanks bridgman and of course also to the other devs working on this one :)



Are you already using ForceLowPowerMode and related options ?

yes I am, I guess:

Option "ForceLowPowerMode" "True"
Option "DynamicPM" "True"
Option "ClockGating" "True"

should be enough ?

I've read that dynamicclocks doesn't work on R600 or R700 or even leads to hardlocks so I've left that disabled ...

kernel is 2.6.30 w. drm and radeon kernel-modules, driver is: xf86-video-ati and mesa (both latest from upstream)

system: ~amd64 Gentoo

[highlandsun]

Yeah, I'm happy to see power management go into the kernel, because that means it will be operating even if I boot up in text mode and never start the X server. (Which I do, quite often, because it still lets me get some work done faster...)

[ssmaxss]

We may need to release some additional HW info in order to finish memory management (specifically interrupts), not sure but looking into it.

It's probably safe to say "either 2.6.31 or 2.6.32" but hard to be more precise.

Any ETA for this interrupts docs? And how is it possible to get it into .31? During -rc state, or it is so simple that you think there is possibility to release docs and code before merge window close? .31 will be great as it will provide huge base of testers from *buntu.

[Zhick]

I've read that dynamicclocks doesn't work on R600 or R700 or even leads to hardlocks so I've left that disabled ...
AFAIK ClockGating == DynamicClocks, it has just been renamed at some point to reflect more clearly what it does.

[bridgman]

Any ETA for this interrupts docs? And how is it possible to get it into .31? During -rc state, or it is so simple that you think there is possibility to release docs and code before merge window close? .31 will be great as it will provide huge base of testers from *buntu.

No ETA on the doc yet; I'm just checking status of patent applications.

What I'm not sure of right now is whether interrupts are needed to make KMS/MM "work" or just to make it "nice". The only way it would get into 2.6.31 would be if the code glisse is already working on could go in without significant changes.

Hardware enablement is always a bit different from other driver/kernel enhancements, since if it's done right the chance breaking existing functionality is essentially zero and the worst that would happen is that the code has problems on some of the new hardware - vs not working at all before. It's one of those "on the fence" cases we'll need to deal with more now that core graphics support is moving into the kernel just like all the other hardware.

[ssmaxss]

What I'm not sure of right now is whether interrupts are needed to make KMS/MM "work" or just to make it "nice". The only way it would get into 2.6.31 would be if the code glisse is already working on could go in without significant changes.
So there is a chance that you can't release docs for interrupts due to some 3rdparty IP, and they are needed to make MM "nice" and OSS drivers end up with crippled MM?
BTW: will we see Friday code drop for r6xx-rewrite today?

[bridgman]

Not third party patent applications, *our* patent applications ;)

It gets complicated if we publicly release information while a patent application is still in flight. Doesn't mean we can't do it, but it affects the schedule.

Richard tracked down the rendering problems with 6xx-rewrite last night to a problem in the new memory management code (in mesa, not in kernel); all we know right now is that if we bypass the memory manager the rest of the driver works.

Next update will probably be when we find and fix the problem; might be today but I doubt it.

[ssmaxss]

Not third party patent applications, *our* patent applications ;)
It gets complicated if we publicly release information while a patent application is still in flight. Doesn't mean we can't do it, but it affects the schedule.
Why don't you just give this docs only to devs under NDA then (till you get patent issues sorted out)?
Good to know that r6xx-rewrite is moving forward :). Will this fix make only redbook hello work properly (with another fix fixing another trivial demo) or it is more like core bug, and code for more complicated things is there, but it doesn't work due to this bug?

[bridgman]

Why don't you just give this docs only to devs under NDA then (till you get patent issues sorted out)?

We have already done that. The problem is that there are a number of different ways to use the hardware depending on which bits we can publicly expose first, so we need to get that sorted out before the devs can write anything more than prototype code.

Good to know that r6xx-rewrite is moving forward :). Will this fix make only redbook hello work properly (with another fix fixing another trivial demo) or it is more like core bug, and code for more complicated things is there, but it doesn't work due to this bug?

It's a core bug which should help in number of areas.

[kernelOfTruth]

AFAIK ClockGating == DynamicClocks, it has just been renamed at some point to reflect more clearly what it does.

thanks !

I just saw it in the logs:

Static power management enable success
(II) RADEON(0): Dynamic Clock Gating Enabled
(II) RADEON(0): Dynamic Power Management Enabled
(II) RADEON(0): Force Low Power Mode Enabled
(II) RADEON(0): Power Mode Switch

Dynamic Clock Gating == Dynamic Clocks (old) == ClockGating (new)

[nanonyme]

Not third party patent applications, *our* patent applications ;)<minor troll>Now, that sounds something that would be a *lot* simpler with Solaris. There you could just grant them right to use the patent, kernel modules would be written using CDDL which recognizes AMD/ATi's patents and everyone would be happy. ;)</minor troll>

[ssmaxss]

As I understand the problem here is not GPL vs patents. They don't want to describe this part of chip, because they haven't yet got patent for it (only patent applications)

btw: as always, will be interesting to hear about any progress with r6xx-rewrite.

[nanonyme]

As I understand the problem here is not GPL vs patents. They don't want to describe this part of chip, because they haven't yet got patent for it (only patent applications)Oh, right. It might well be a hardware patent. (which would go way beyond the scope of GPL's anti-patent agenda)

[bridgman]

Yes, any time I talk about patents with relation to providing programming info we're talking about hardware patents.

[ssmaxss]

Richard tracked down the rendering problems with 6xx-rewrite last night to a problem in the new memory management code (in mesa, not in kernel); all we know right now is that if we bypass the memory manager the rest of the driver works.
Any updates on this? Looks like last major commit to r6xx-rewrite was 12 days ago...

[bridgman]

Yeah, latest news (from a couple of hours ago) is that the problem is that we were adding the buffer offset twice; once in mesa and once in drm. Adding the offset in drm was a relatively recent change suggested to improve compatibility with the GEM/TTM scenario, but looks like we were still adding it in mesa as well. The fix should go into mesa AFAIK.

There were some bug fixes in 6xx-rewrite a few days ago, but until the memory manager issue is fixed it's kinda hard to make progress on anything else.

[ssmaxss]

Cool. Is there a patch for that offset bug somewhere? Will this fix allow to enable clear code, that gives redbook hello background proper color?

Is the term "memory manager" used to describe two different things in context of mesa driver (where it exists, but contains bugs) and KMS (where it doesn't exist)? e.g.: couldn't mesa's memory manager be reused for KMS purposes.

[bridgman]

No patch yet; as soon as we have a fix it will get pushed into the public repo. All I know so far is that when Richard bypassed the memory management completely both clear and shader ops worked - what I don't know is whether this offset issue is the only problem we're having in the memory manager or just the first.

I haven't had a chance to go through the code yet, but as I understand it the memory management code we're dealing with here (bufmgr/cs in mesa plus the correspoinding code in drm) is something similar to the old userspace memory management code but with an API much closer to the GEM/TTM implementation going into the kernel. It doesn't have all the capabilities of the GEM/TTM code in the kernel though...