* [PATCH 0/2] kvmtool: Enable overriding Generic Timer frequency @ 2013-12-17 18:31 ` Robin Murphy 0 siblings, 0 replies; 14+ messages in thread From: Robin Murphy @ 2013-12-17 18:31 UTC (permalink / raw) To: linux-arm-kernel This patch series allows (but discourages) overriding the Generic Timer frequency for device tree-based guest OSes, to work around systems with broken secure firmware that fails to program CNTFRQ correctly. Robin Murphy (2): kvmtool: Support unsigned int options kvmtool/arm: Add option to override Generic Timer frequency tools/kvm/arm/include/arm-common/kvm-config-arch.h | 15 ++++++++++----- tools/kvm/arm/timer.c | 2 ++ tools/kvm/include/kvm/parse-options.h | 9 +++++++++ 3 files changed, 21 insertions(+), 5 deletions(-) -- 1.7.9.5 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 0/2] kvmtool: Enable overriding Generic Timer frequency @ 2013-12-17 18:31 ` Robin Murphy 0 siblings, 0 replies; 14+ messages in thread From: Robin Murphy @ 2013-12-17 18:31 UTC (permalink / raw) To: linux-arm-kernel, kvmarm; +Cc: kvm, will.deacon, Robin Murphy This patch series allows (but discourages) overriding the Generic Timer frequency for device tree-based guest OSes, to work around systems with broken secure firmware that fails to program CNTFRQ correctly. Robin Murphy (2): kvmtool: Support unsigned int options kvmtool/arm: Add option to override Generic Timer frequency tools/kvm/arm/include/arm-common/kvm-config-arch.h | 15 ++++++++++----- tools/kvm/arm/timer.c | 2 ++ tools/kvm/include/kvm/parse-options.h | 9 +++++++++ 3 files changed, 21 insertions(+), 5 deletions(-) -- 1.7.9.5 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 1/2] kvmtool: Support unsigned int options 2013-12-17 18:31 ` Robin Murphy @ 2013-12-17 18:31 ` Robin Murphy -1 siblings, 0 replies; 14+ messages in thread From: Robin Murphy @ 2013-12-17 18:31 UTC (permalink / raw) To: linux-arm-kernel Add support for unsigned int command-line options by implementing the OPT_UINTEGER macro. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> --- tools/kvm/include/kvm/parse-options.h | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/tools/kvm/include/kvm/parse-options.h b/tools/kvm/include/kvm/parse-options.h index 09a5fca..b03f151 100644 --- a/tools/kvm/include/kvm/parse-options.h +++ b/tools/kvm/include/kvm/parse-options.h @@ -109,6 +109,15 @@ struct option { .help = (h) \ } +#define OPT_UINTEGER(s, l, v, h) \ +{ \ + .type = OPTION_UINTEGER, \ + .short_name = (s), \ + .long_name = (l), \ + .value = check_vtype(v, unsigned int *), \ + .help = (h) \ +} + #define OPT_U64(s, l, v, h) \ { \ .type = OPTION_U64, \ -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 1/2] kvmtool: Support unsigned int options @ 2013-12-17 18:31 ` Robin Murphy 0 siblings, 0 replies; 14+ messages in thread From: Robin Murphy @ 2013-12-17 18:31 UTC (permalink / raw) To: linux-arm-kernel, kvmarm; +Cc: kvm, will.deacon, Robin Murphy Add support for unsigned int command-line options by implementing the OPT_UINTEGER macro. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> --- tools/kvm/include/kvm/parse-options.h | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/tools/kvm/include/kvm/parse-options.h b/tools/kvm/include/kvm/parse-options.h index 09a5fca..b03f151 100644 --- a/tools/kvm/include/kvm/parse-options.h +++ b/tools/kvm/include/kvm/parse-options.h @@ -109,6 +109,15 @@ struct option { .help = (h) \ } +#define OPT_UINTEGER(s, l, v, h) \ +{ \ + .type = OPTION_UINTEGER, \ + .short_name = (s), \ + .long_name = (l), \ + .value = check_vtype(v, unsigned int *), \ + .help = (h) \ +} + #define OPT_U64(s, l, v, h) \ { \ .type = OPTION_U64, \ -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 2/2] kvmtool/arm: Add option to override Generic Timer frequency 2013-12-17 18:31 ` Robin Murphy @ 2013-12-17 18:31 ` Robin Murphy -1 siblings, 0 replies; 14+ messages in thread From: Robin Murphy @ 2013-12-17 18:31 UTC (permalink / raw) To: linux-arm-kernel Some platforms have secure firmware which does not correctly set the CNTFRQ register on boot, preventing the use of the Generic Timer. This patch allows mirroring the necessary host workaround by specifying the clock-frequency property in the guest DT. This should only be considered a means of KVM bring-up on such systems, such that vendors may be convinced to properly implement their firmware to support the virtualisation capabilities of their hardware. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> --- tools/kvm/arm/include/arm-common/kvm-config-arch.h | 15 ++++++++++----- tools/kvm/arm/timer.c | 2 ++ 2 files changed, 12 insertions(+), 5 deletions(-) diff --git a/tools/kvm/arm/include/arm-common/kvm-config-arch.h b/tools/kvm/arm/include/arm-common/kvm-config-arch.h index 7ac6f6e..f3baf39 100644 --- a/tools/kvm/arm/include/arm-common/kvm-config-arch.h +++ b/tools/kvm/arm/include/arm-common/kvm-config-arch.h @@ -5,13 +5,18 @@ struct kvm_config_arch { const char *dump_dtb_filename; + unsigned int force_cntfrq; bool aarch32_guest; }; -#define OPT_ARCH_RUN(pfx, cfg) \ - pfx, \ - ARM_OPT_ARCH_RUN(cfg) \ - OPT_STRING('\0', "dump-dtb", &(cfg)->dump_dtb_filename, \ - ".dtb file", "Dump generated .dtb to specified file"), +#define OPT_ARCH_RUN(pfx, cfg) \ + pfx, \ + ARM_OPT_ARCH_RUN(cfg) \ + OPT_STRING('\0', "dump-dtb", &(cfg)->dump_dtb_filename, \ + ".dtb file", "Dump generated .dtb to specified file"), \ + OPT_UINTEGER('\0', "override-bad-firmware-cntfrq", &(cfg)->force_cntfrq,\ + "Specify Generic Timer frequency in guest DT to " \ + "work around buggy secure firmware *Firmware should be " \ + "updated to program CNTFRQ correctly*"), #endif /* ARM_COMMON__KVM_CONFIG_ARCH_H */ diff --git a/tools/kvm/arm/timer.c b/tools/kvm/arm/timer.c index bd6a0bb..d757c1d 100644 --- a/tools/kvm/arm/timer.c +++ b/tools/kvm/arm/timer.c @@ -33,6 +33,8 @@ void timer__generate_fdt_nodes(void *fdt, struct kvm *kvm, int *irqs) _FDT(fdt_begin_node(fdt, "timer")); _FDT(fdt_property(fdt, "compatible", compatible, sizeof(compatible))); _FDT(fdt_property(fdt, "interrupts", irq_prop, sizeof(irq_prop))); + if (kvm->cfg.arch.force_cntfrq > 0) + _FDT(fdt_property_cell(fdt, "clock-frequency", kvm->cfg.arch.force_cntfrq)); _FDT(fdt_end_node(fdt)); } -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 2/2] kvmtool/arm: Add option to override Generic Timer frequency @ 2013-12-17 18:31 ` Robin Murphy 0 siblings, 0 replies; 14+ messages in thread From: Robin Murphy @ 2013-12-17 18:31 UTC (permalink / raw) To: linux-arm-kernel, kvmarm; +Cc: kvm, will.deacon, Robin Murphy Some platforms have secure firmware which does not correctly set the CNTFRQ register on boot, preventing the use of the Generic Timer. This patch allows mirroring the necessary host workaround by specifying the clock-frequency property in the guest DT. This should only be considered a means of KVM bring-up on such systems, such that vendors may be convinced to properly implement their firmware to support the virtualisation capabilities of their hardware. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> --- tools/kvm/arm/include/arm-common/kvm-config-arch.h | 15 ++++++++++----- tools/kvm/arm/timer.c | 2 ++ 2 files changed, 12 insertions(+), 5 deletions(-) diff --git a/tools/kvm/arm/include/arm-common/kvm-config-arch.h b/tools/kvm/arm/include/arm-common/kvm-config-arch.h index 7ac6f6e..f3baf39 100644 --- a/tools/kvm/arm/include/arm-common/kvm-config-arch.h +++ b/tools/kvm/arm/include/arm-common/kvm-config-arch.h @@ -5,13 +5,18 @@ struct kvm_config_arch { const char *dump_dtb_filename; + unsigned int force_cntfrq; bool aarch32_guest; }; -#define OPT_ARCH_RUN(pfx, cfg) \ - pfx, \ - ARM_OPT_ARCH_RUN(cfg) \ - OPT_STRING('\0', "dump-dtb", &(cfg)->dump_dtb_filename, \ - ".dtb file", "Dump generated .dtb to specified file"), +#define OPT_ARCH_RUN(pfx, cfg) \ + pfx, \ + ARM_OPT_ARCH_RUN(cfg) \ + OPT_STRING('\0', "dump-dtb", &(cfg)->dump_dtb_filename, \ + ".dtb file", "Dump generated .dtb to specified file"), \ + OPT_UINTEGER('\0', "override-bad-firmware-cntfrq", &(cfg)->force_cntfrq,\ + "Specify Generic Timer frequency in guest DT to " \ + "work around buggy secure firmware *Firmware should be " \ + "updated to program CNTFRQ correctly*"), #endif /* ARM_COMMON__KVM_CONFIG_ARCH_H */ diff --git a/tools/kvm/arm/timer.c b/tools/kvm/arm/timer.c index bd6a0bb..d757c1d 100644 --- a/tools/kvm/arm/timer.c +++ b/tools/kvm/arm/timer.c @@ -33,6 +33,8 @@ void timer__generate_fdt_nodes(void *fdt, struct kvm *kvm, int *irqs) _FDT(fdt_begin_node(fdt, "timer")); _FDT(fdt_property(fdt, "compatible", compatible, sizeof(compatible))); _FDT(fdt_property(fdt, "interrupts", irq_prop, sizeof(irq_prop))); + if (kvm->cfg.arch.force_cntfrq > 0) + _FDT(fdt_property_cell(fdt, "clock-frequency", kvm->cfg.arch.force_cntfrq)); _FDT(fdt_end_node(fdt)); } -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 2/2] kvmtool/arm: Add option to override Generic Timer frequency 2013-12-17 18:31 ` Robin Murphy @ 2013-12-17 20:39 ` Alexander Graf -1 siblings, 0 replies; 14+ messages in thread From: Alexander Graf @ 2013-12-17 20:39 UTC (permalink / raw) To: linux-arm-kernel On 17.12.2013, at 19:31, Robin Murphy <robin.murphy@arm.com> wrote: > Some platforms have secure firmware which does not correctly set the > CNTFRQ register on boot, preventing the use of the Generic Timer. > This patch allows mirroring the necessary host workaround by specifying > the clock-frequency property in the guest DT. > > This should only be considered a means of KVM bring-up on such systems, > such that vendors may be convinced to properly implement their firmware > to support the virtualisation capabilities of their hardware. > > Signed-off-by: Robin Murphy <robin.murphy@arm.com> > Acked-by: Will Deacon <will.deacon@arm.com> How does it encourage a vendor to properly implement their firmware if there's a workaround? Alex ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/2] kvmtool/arm: Add option to override Generic Timer frequency @ 2013-12-17 20:39 ` Alexander Graf 0 siblings, 0 replies; 14+ messages in thread From: Alexander Graf @ 2013-12-17 20:39 UTC (permalink / raw) To: Robin Murphy Cc: linux-arm-kernel, kvmarm, Will Deacon, kvm@vger.kernel.org mailing list On 17.12.2013, at 19:31, Robin Murphy <robin.murphy@arm.com> wrote: > Some platforms have secure firmware which does not correctly set the > CNTFRQ register on boot, preventing the use of the Generic Timer. > This patch allows mirroring the necessary host workaround by specifying > the clock-frequency property in the guest DT. > > This should only be considered a means of KVM bring-up on such systems, > such that vendors may be convinced to properly implement their firmware > to support the virtualisation capabilities of their hardware. > > Signed-off-by: Robin Murphy <robin.murphy@arm.com> > Acked-by: Will Deacon <will.deacon@arm.com> How does it encourage a vendor to properly implement their firmware if there's a workaround? Alex ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 2/2] kvmtool/arm: Add option to override Generic Timer frequency 2013-12-17 20:39 ` Alexander Graf @ 2013-12-18 13:44 ` Robin Murphy -1 siblings, 0 replies; 14+ messages in thread From: Robin Murphy @ 2013-12-18 13:44 UTC (permalink / raw) To: linux-arm-kernel On 17/12/13 20:39, Alexander Graf wrote: > > On 17.12.2013, at 19:31, Robin Murphy <robin.murphy@arm.com> wrote: > >> Some platforms have secure firmware which does not correctly set the >> CNTFRQ register on boot, preventing the use of the Generic Timer. >> This patch allows mirroring the necessary host workaround by specifying >> the clock-frequency property in the guest DT. >> >> This should only be considered a means of KVM bring-up on such systems, >> such that vendors may be convinced to properly implement their firmware >> to support the virtualisation capabilities of their hardware. >> >> Signed-off-by: Robin Murphy <robin.murphy@arm.com> >> Acked-by: Will Deacon <will.deacon@arm.com> > > How does it encourage a vendor to properly implement their firmware if there's a workaround? > > > Alex > > Hi Alex, In short, by enabling the users to create the demand. Yes, like any workaround there's potential for abuse, but having *something* that makes it work is the difference between "I want virtualisation"[1] and "Dear vendor, I've tried virtualisation on your chip/board and it's great, but it tells me I need new firmware, where do I get that?" Having the specs tell them what to do clearly isn't sufficient, so let's give the integrators and consumers incentive to shout at them too. The sooner proper support is commonplace and we can deprecate clock-frequency hacks altogether, the better. Robin. [1] http://www.theregister.co.uk/2013/12/12/virtualisation_on_mobile_phones_is_coming/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/2] kvmtool/arm: Add option to override Generic Timer frequency @ 2013-12-18 13:44 ` Robin Murphy 0 siblings, 0 replies; 14+ messages in thread From: Robin Murphy @ 2013-12-18 13:44 UTC (permalink / raw) To: Alexander Graf Cc: linux-arm-kernel, kvmarm@lists.cs.columbia.edu, Will Deacon, kvm@vger.kernel.org mailing list On 17/12/13 20:39, Alexander Graf wrote: > > On 17.12.2013, at 19:31, Robin Murphy <robin.murphy@arm.com> wrote: > >> Some platforms have secure firmware which does not correctly set the >> CNTFRQ register on boot, preventing the use of the Generic Timer. >> This patch allows mirroring the necessary host workaround by specifying >> the clock-frequency property in the guest DT. >> >> This should only be considered a means of KVM bring-up on such systems, >> such that vendors may be convinced to properly implement their firmware >> to support the virtualisation capabilities of their hardware. >> >> Signed-off-by: Robin Murphy <robin.murphy@arm.com> >> Acked-by: Will Deacon <will.deacon@arm.com> > > How does it encourage a vendor to properly implement their firmware if there's a workaround? > > > Alex > > Hi Alex, In short, by enabling the users to create the demand. Yes, like any workaround there's potential for abuse, but having *something* that makes it work is the difference between "I want virtualisation"[1] and "Dear vendor, I've tried virtualisation on your chip/board and it's great, but it tells me I need new firmware, where do I get that?" Having the specs tell them what to do clearly isn't sufficient, so let's give the integrators and consumers incentive to shout at them too. The sooner proper support is commonplace and we can deprecate clock-frequency hacks altogether, the better. Robin. [1] http://www.theregister.co.uk/2013/12/12/virtualisation_on_mobile_phones_is_coming/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 2/2] kvmtool/arm: Add option to override Generic Timer frequency 2013-12-18 13:44 ` Robin Murphy @ 2013-12-18 14:07 ` Alexander Graf -1 siblings, 0 replies; 14+ messages in thread From: Alexander Graf @ 2013-12-18 14:07 UTC (permalink / raw) To: linux-arm-kernel On 18.12.2013, at 14:44, Robin Murphy <robin.murphy@arm.com> wrote: > On 17/12/13 20:39, Alexander Graf wrote: >> >> On 17.12.2013, at 19:31, Robin Murphy <robin.murphy@arm.com> wrote: >> >>> Some platforms have secure firmware which does not correctly set the >>> CNTFRQ register on boot, preventing the use of the Generic Timer. >>> This patch allows mirroring the necessary host workaround by specifying >>> the clock-frequency property in the guest DT. >>> >>> This should only be considered a means of KVM bring-up on such systems, >>> such that vendors may be convinced to properly implement their firmware >>> to support the virtualisation capabilities of their hardware. >>> >>> Signed-off-by: Robin Murphy <robin.murphy@arm.com> >>> Acked-by: Will Deacon <will.deacon@arm.com> >> >> How does it encourage a vendor to properly implement their firmware if there's a workaround? >> >> >> Alex >> >> > > Hi Alex, > > In short, by enabling the users to create the demand. Yes, like any workaround there's potential for abuse, but having *something* that makes it work is the difference between "I want virtualisation"[1] and "Dear vendor, I've tried virtualisation on your chip/board and it's great, but it tells me I need new firmware, where do I get that?" > > Having the specs tell them what to do clearly isn't sufficient, so let's give the integrators and consumers incentive to shout at them too. The sooner proper support is commonplace and we can deprecate clock-frequency hacks altogether, the better. Oh, I'm all for hacks. But please don't fall under the illusion that this will push vendors to fix their firmware. It will have the opposite effect - vendors will just point to the workaround and say "but it works" :). Either way, this hack is basically required because you can't program CNTFRQ because it's controlled by secure firmware, right? So the host os already needs to know about this and probably does have a "clock-frequency" value in its device tree entry already to know how fast its clock ticks. Couldn't we search for that host entry and automatically pass it into the guest if it's there? That way the whole thing becomes seamless and even less of an issue. Alex ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/2] kvmtool/arm: Add option to override Generic Timer frequency @ 2013-12-18 14:07 ` Alexander Graf 0 siblings, 0 replies; 14+ messages in thread From: Alexander Graf @ 2013-12-18 14:07 UTC (permalink / raw) To: Robin Murphy Cc: linux-arm-kernel, kvmarm@lists.cs.columbia.edu, Will Deacon, kvm@vger.kernel.org mailing list On 18.12.2013, at 14:44, Robin Murphy <robin.murphy@arm.com> wrote: > On 17/12/13 20:39, Alexander Graf wrote: >> >> On 17.12.2013, at 19:31, Robin Murphy <robin.murphy@arm.com> wrote: >> >>> Some platforms have secure firmware which does not correctly set the >>> CNTFRQ register on boot, preventing the use of the Generic Timer. >>> This patch allows mirroring the necessary host workaround by specifying >>> the clock-frequency property in the guest DT. >>> >>> This should only be considered a means of KVM bring-up on such systems, >>> such that vendors may be convinced to properly implement their firmware >>> to support the virtualisation capabilities of their hardware. >>> >>> Signed-off-by: Robin Murphy <robin.murphy@arm.com> >>> Acked-by: Will Deacon <will.deacon@arm.com> >> >> How does it encourage a vendor to properly implement their firmware if there's a workaround? >> >> >> Alex >> >> > > Hi Alex, > > In short, by enabling the users to create the demand. Yes, like any workaround there's potential for abuse, but having *something* that makes it work is the difference between "I want virtualisation"[1] and "Dear vendor, I've tried virtualisation on your chip/board and it's great, but it tells me I need new firmware, where do I get that?" > > Having the specs tell them what to do clearly isn't sufficient, so let's give the integrators and consumers incentive to shout at them too. The sooner proper support is commonplace and we can deprecate clock-frequency hacks altogether, the better. Oh, I'm all for hacks. But please don't fall under the illusion that this will push vendors to fix their firmware. It will have the opposite effect - vendors will just point to the workaround and say "but it works" :). Either way, this hack is basically required because you can't program CNTFRQ because it's controlled by secure firmware, right? So the host os already needs to know about this and probably does have a "clock-frequency" value in its device tree entry already to know how fast its clock ticks. Couldn't we search for that host entry and automatically pass it into the guest if it's there? That way the whole thing becomes seamless and even less of an issue. Alex ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 2/2] kvmtool/arm: Add option to override Generic Timer frequency 2013-12-18 14:07 ` Alexander Graf @ 2013-12-18 16:11 ` Robin Murphy -1 siblings, 0 replies; 14+ messages in thread From: Robin Murphy @ 2013-12-18 16:11 UTC (permalink / raw) To: linux-arm-kernel On 18/12/13 14:07, Alexander Graf wrote: > [...] >>> How does it encourage a vendor to properly implement their firmware if there's a workaround? >>> >>> >>> Alex >>> >>> >> >> Hi Alex, >> >> In short, by enabling the users to create the demand. Yes, like any workaround there's potential for abuse, but having *something* that makes it work is the difference between "I want virtualisation"[1] and "Dear vendor, I've tried virtualisation on your chip/board and it's great, but it tells me I need new firmware, where do I get that?" >> >> Having the specs tell them what to do clearly isn't sufficient, so let's give the integrators and consumers incentive to shout at them too. The sooner proper support is commonplace and we can deprecate clock-frequency hacks altogether, the better. > > Oh, I'm all for hacks. But please don't fall under the illusion that this will push vendors to fix their firmware. It will have the opposite effect - vendors will just point to the workaround and say "but it works" :). > If vendors already aren't bothering to support functionality available in their flagship hardware, workarounds hardly make that worse, and are a win for the user. If it can drive adoption enough to get vendors to see the value in at least fixing future products, that's only good. > Either way, this hack is basically required because you can't program CNTFRQ because it's controlled by secure firmware, right? So the host os already needs to know about this and probably does have a "clock-frequency" value in its device tree entry already to know how fast its clock ticks. > In some cases, yes. In others they don't explicitly use the arch timer at all thus have no frequency set anywhere. In the case of the board I have on my desk, it took hacking the non-secure part of the bootloader, writing a shim to throw away the securely-booted non-hyp cpu0 and fire up a secondary, and hacking a timer node into the host DT to even get as far as having an issue with kvmtool. > Couldn't we search for that host entry and automatically pass it into the guest if it's there? That way the whole thing becomes seamless and even less of an issue. > In theory that would be an ideal solution, yes. In practice it means either making KVM dependent on PROC_DEVICETREE (yuck) or cooking up some kernel interface to expose the system timer frequency to userspace (double yuck). Not just "global solution to local problem", but "global solution to local problem-that-shouldn't-even-exist-and-you-want-to-go-away-as-soon-as-possible-without-leaving-a-legacy". Besides, that would probably just reinforce the equally wrong behaviour of putting the frequency in the host DT instead of fixing the firmware ;) Robin. > > Alex > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/2] kvmtool/arm: Add option to override Generic Timer frequency @ 2013-12-18 16:11 ` Robin Murphy 0 siblings, 0 replies; 14+ messages in thread From: Robin Murphy @ 2013-12-18 16:11 UTC (permalink / raw) To: Alexander Graf Cc: linux-arm-kernel, kvmarm@lists.cs.columbia.edu, Will Deacon, kvm@vger.kernel.org mailing list On 18/12/13 14:07, Alexander Graf wrote: > [...] >>> How does it encourage a vendor to properly implement their firmware if there's a workaround? >>> >>> >>> Alex >>> >>> >> >> Hi Alex, >> >> In short, by enabling the users to create the demand. Yes, like any workaround there's potential for abuse, but having *something* that makes it work is the difference between "I want virtualisation"[1] and "Dear vendor, I've tried virtualisation on your chip/board and it's great, but it tells me I need new firmware, where do I get that?" >> >> Having the specs tell them what to do clearly isn't sufficient, so let's give the integrators and consumers incentive to shout at them too. The sooner proper support is commonplace and we can deprecate clock-frequency hacks altogether, the better. > > Oh, I'm all for hacks. But please don't fall under the illusion that this will push vendors to fix their firmware. It will have the opposite effect - vendors will just point to the workaround and say "but it works" :). > If vendors already aren't bothering to support functionality available in their flagship hardware, workarounds hardly make that worse, and are a win for the user. If it can drive adoption enough to get vendors to see the value in at least fixing future products, that's only good. > Either way, this hack is basically required because you can't program CNTFRQ because it's controlled by secure firmware, right? So the host os already needs to know about this and probably does have a "clock-frequency" value in its device tree entry already to know how fast its clock ticks. > In some cases, yes. In others they don't explicitly use the arch timer at all thus have no frequency set anywhere. In the case of the board I have on my desk, it took hacking the non-secure part of the bootloader, writing a shim to throw away the securely-booted non-hyp cpu0 and fire up a secondary, and hacking a timer node into the host DT to even get as far as having an issue with kvmtool. > Couldn't we search for that host entry and automatically pass it into the guest if it's there? That way the whole thing becomes seamless and even less of an issue. > In theory that would be an ideal solution, yes. In practice it means either making KVM dependent on PROC_DEVICETREE (yuck) or cooking up some kernel interface to expose the system timer frequency to userspace (double yuck). Not just "global solution to local problem", but "global solution to local problem-that-shouldn't-even-exist-and-you-want-to-go-away-as-soon-as-possible-without-leaving-a-legacy". Besides, that would probably just reinforce the equally wrong behaviour of putting the frequency in the host DT instead of fixing the firmware ;) Robin. > > Alex > > ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-12-18 16:11 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-12-17 18:31 [PATCH 0/2] kvmtool: Enable overriding Generic Timer frequency Robin Murphy 2013-12-17 18:31 ` Robin Murphy 2013-12-17 18:31 ` [PATCH 1/2] kvmtool: Support unsigned int options Robin Murphy 2013-12-17 18:31 ` Robin Murphy 2013-12-17 18:31 ` [PATCH 2/2] kvmtool/arm: Add option to override Generic Timer frequency Robin Murphy 2013-12-17 18:31 ` Robin Murphy 2013-12-17 20:39 ` Alexander Graf 2013-12-17 20:39 ` Alexander Graf 2013-12-18 13:44 ` Robin Murphy 2013-12-18 13:44 ` Robin Murphy 2013-12-18 14:07 ` Alexander Graf 2013-12-18 14:07 ` Alexander Graf 2013-12-18 16:11 ` Robin Murphy 2013-12-18 16:11 ` Robin Murphy
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.