| Message ID | 1414579302-6692-18-git-send-email-ian.campbell@citrix.com |
|---|---|
| State | New |
| Headers | show |
Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"):
> This stops dom0 from messing with clocks which it should and is required on
> some platforms. It's harmless even when not needed.
This is pretty odd. Doesn't this correspond to some kind of bug, in
the dom0 kernel perhaps ?
Ian.
create ! title it arm: domain 0 disables clocks which are in fact being used thanks On Wed, 2014-10-29 at 16:39 +0000, Ian Jackson wrote: > Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"): > > This stops dom0 from messing with clocks which it should and is required on > > some platforms. It's harmless even when not needed. > > This is pretty odd. Doesn't this correspond to some kind of bug, in > the dom0 kernel perhaps ? dom0 is not aware that some clocks are actually in use (e.g. by the hypervisor), so the bug is probably in the lack of some interface to communicate this from Xen to dom0, or some other mechanism to gate this. I think some or all of the above ought to be added to the commit message, and perhaps in a comment too. Along with a reference to the bug which this mail should be about to create. Would you like me to do anything else? Ian.
Processing commands for xen@bugs.xenproject.org: > create ! Created new bug #45 rooted at `<1414672390.2064.31.camel@citrix.com>' Title: `Re: [PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line' > title it arm: domain 0 disables clocks which are in fact being used Set title for #45 to `arm: domain 0 disables clocks which are in fact being used' > thanks Finished processing. Modified/created Bugs: - 45: http://bugs.xenproject.org/xen/bug/45 (new) --- Xen Hypervisor Bug Tracker See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on reporting bugs Contact xen-bugs-owner@bugs.xenproject.org with any infrastructure issues
Ian Campbell writes ("Re: [PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"):
> create !
> title it arm: domain 0 disables clocks which are in fact being used
> thanks
...
> dom0 is not aware that some clocks are actually in use (e.g. by the
> hypervisor), so the bug is probably in the lack of some interface to
> communicate this from Xen to dom0, or some other mechanism to gate this.
Right.
> I think some or all of the above ought to be added to the commit
> message, and perhaps in a comment too. Along with a reference to the bug
> which this mail should be about to create. Would you like me to do
> anything else?
I think that's enough, thanks.
Ian.
Hi, Somehow I missed this email. On 30/10/2014 13:33, Ian Campbell wrote: > create ! > title it arm: domain 0 disables clocks which are in fact being used > thanks > > On Wed, 2014-10-29 at 16:39 +0000, Ian Jackson wrote: >> Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"): >>> This stops dom0 from messing with clocks which it should and is required on >>> some platforms. It's harmless even when not needed. >> >> This is pretty odd. Doesn't this correspond to some kind of bug, in >> the dom0 kernel perhaps ? > > dom0 is not aware that some clocks are actually in use (e.g. by the > hypervisor), so the bug is probably in the lack of some interface to > communicate this from Xen to dom0, or some other mechanism to gate this. In reality, Xen is only using the clock of the UART. Even though, I think this would also happen with platform device passthrough. For the latter, it would be fairly easy via a PV drivers. But for UART... gating the clock could be a nightmare because every platform have their own way to enable/disable the clock. Futhermore, the clock could be shared with multiple device... I'm wondering if we could expose the UART to DOM0 without marking as disabled. It would avoid DOM0 to mess up the clock while everything would be catch via the vuart implementation in Xen. Regards,
On Tue, 2014-11-11 at 17:50 +0100, Julien Grall wrote: > Hi, > > Somehow I missed this email. > > On 30/10/2014 13:33, Ian Campbell wrote: > > create ! > > title it arm: domain 0 disables clocks which are in fact being used > > thanks > > > > On Wed, 2014-10-29 at 16:39 +0000, Ian Jackson wrote: > >> Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"): > >>> This stops dom0 from messing with clocks which it should and is required on > >>> some platforms. It's harmless even when not needed. > >> > >> This is pretty odd. Doesn't this correspond to some kind of bug, in > >> the dom0 kernel perhaps ? > > > > dom0 is not aware that some clocks are actually in use (e.g. by the > > hypervisor), so the bug is probably in the lack of some interface to > > communicate this from Xen to dom0, or some other mechanism to gate this. > > In reality, Xen is only using the clock of the UART. Even though, I > think this would also happen with platform device passthrough. > > For the latter, it would be fairly easy via a PV drivers. But for > UART... gating the clock could be a nightmare because every platform > have their own way to enable/disable the clock. Futhermore, the clock > could be shared with multiple device... > > I'm wondering if we could expose the UART to DOM0 without marking as > disabled. It would avoid DOM0 to mess up the clock while everything > would be catch via the vuart implementation in Xen. Perhaps we could propagate any clock related properties from the UART node into the Xen hypervisor node (or a subnode)? The Xen Linux code would then consume those and mark the relevant clocks as in use. I've not looked into the clock bindings to know how plausible this might be. Ian.
On 11/12/2014 10:07 AM, Ian Campbell wrote: > On Tue, 2014-11-11 at 17:50 +0100, Julien Grall wrote: >> Hi, >> >> Somehow I missed this email. >> >> On 30/10/2014 13:33, Ian Campbell wrote: >>> create ! >>> title it arm: domain 0 disables clocks which are in fact being used >>> thanks >>> >>> On Wed, 2014-10-29 at 16:39 +0000, Ian Jackson wrote: >>>> Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"): >>>>> This stops dom0 from messing with clocks which it should and is required on >>>>> some platforms. It's harmless even when not needed. >>>> >>>> This is pretty odd. Doesn't this correspond to some kind of bug, in >>>> the dom0 kernel perhaps ? >>> >>> dom0 is not aware that some clocks are actually in use (e.g. by the >>> hypervisor), so the bug is probably in the lack of some interface to >>> communicate this from Xen to dom0, or some other mechanism to gate this. >> >> In reality, Xen is only using the clock of the UART. Even though, I >> think this would also happen with platform device passthrough. >> >> For the latter, it would be fairly easy via a PV drivers. But for >> UART... gating the clock could be a nightmare because every platform >> have their own way to enable/disable the clock. Futhermore, the clock >> could be shared with multiple device... >> >> I'm wondering if we could expose the UART to DOM0 without marking as >> disabled. It would avoid DOM0 to mess up the clock while everything >> would be catch via the vuart implementation in Xen. > > Perhaps we could propagate any clock related properties from the UART > node into the Xen hypervisor node (or a subnode)? The Xen Linux code > would then consume those and mark the relevant clocks as in use. I've > not looked into the clock bindings to know how plausible this might be. It looks like the bindings for clock is well defined and fairly common (Documentation/devicetree/bindins/clock/clock-bindings.txt). So your solution sounds plausible. Regards,
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm index 0e808a0..eb7464c 100644 --- a/Osstest/Debian.pm +++ b/Osstest/Debian.pm @@ -171,7 +171,7 @@ ext2load scsi 0 \\\${kernel_addr_r} $kern fdt mknod /chosen module\@0 fdt set /chosen/module\@0 compatible "xen,linux-zimage" "xen,multiboot-module" fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} \\\${filesize}> -fdt set /chosen/module\@0 bootargs "$xenkopt ro root=$root" +fdt set /chosen/module\@0 bootargs "$xenkopt ro root=$root clk_ignore_unused" echo Loaded $kern to \\\${kernel_addr_r} (\\\${filesize}) echo command line: $xenkopt ro root=$root
This stops dom0 from messing with clocks which it should and is required on some platforms. It's harmless even when not needed. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> --- v2: New patch, previously incorrectly included in "Osstest/Debian: Workaround oddities in the u-boot script parser." --- Osstest/Debian.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)