* [PATCH kvmtool] rtc: Generate fdt node for the real-time clock @ 2020-05-14 9:45 Andre Przywara 2020-05-14 12:20 ` Mark Rutland 2020-05-19 16:46 ` Will Deacon 0 siblings, 2 replies; 4+ messages in thread From: Andre Przywara @ 2020-05-14 9:45 UTC (permalink / raw) To: Will Deacon, Julien Thierry; +Cc: Sami Mujawar, kvmarm, kvm On arm and arm64 we expose the Motorola RTC emulation to the guest, but never advertised this in the device tree. EDK-2 seems to rely on this device, but on its hardcoded address. To make this more future-proof, add a DT node with the address in it. EDK-2 can then read the proper address from there, and we can change this address later (with the flexible memory layout). Please note that an arm64 Linux kernel is not ready to use this device, there are some include files missing under arch/arm64 to compile the driver. I hacked this up in the kernel, just to verify this DT snippet is correct, but don't see much value in enabling this properly in Linux. Signed-off-by: Andre Przywara <andre.przywara@arm.com> --- hw/rtc.c | 44 ++++++++++++++++++++++++++++++++++++++------ 1 file changed, 38 insertions(+), 6 deletions(-) diff --git a/hw/rtc.c b/hw/rtc.c index c1fa72f2..5483879f 100644 --- a/hw/rtc.c +++ b/hw/rtc.c @@ -130,24 +130,56 @@ static struct ioport_operations cmos_ram_index_ioport_ops = { .io_out = cmos_ram_index_out, }; +#ifdef CONFIG_HAS_LIBFDT +static void generate_rtc_fdt_node(void *fdt, + struct device_header *dev_hdr, + void (*generate_irq_prop)(void *fdt, + u8 irq, + enum irq_type)) +{ + u64 reg_prop[2] = { cpu_to_fdt64(0x70), cpu_to_fdt64(2) }; + + _FDT(fdt_begin_node(fdt, "rtc")); + _FDT(fdt_property_string(fdt, "compatible", "motorola,mc146818")); + _FDT(fdt_property(fdt, "reg", reg_prop, sizeof(reg_prop))); + _FDT(fdt_end_node(fdt)); +} +#else +#define generate_rtc_fdt_node NULL +#endif + +struct device_header rtc_dev_hdr = { + .bus_type = DEVICE_BUS_IOPORT, + .data = generate_rtc_fdt_node, +}; + int rtc__init(struct kvm *kvm) { - int r = 0; + int r; + + r = device__register(&rtc_dev_hdr); + if (r < 0) + return r; /* PORT 0070-007F - CMOS RAM/RTC (REAL TIME CLOCK) */ r = ioport__register(kvm, 0x0070, &cmos_ram_index_ioport_ops, 1, NULL); if (r < 0) - return r; + goto out_device; r = ioport__register(kvm, 0x0071, &cmos_ram_data_ioport_ops, 1, NULL); - if (r < 0) { - ioport__unregister(kvm, 0x0071); - return r; - } + if (r < 0) + goto out_ioport; /* Set the VRT bit in Register D to indicate valid RAM and time */ rtc.cmos_data[RTC_REG_D] = RTC_REG_D_VRT; + return r; + +out_ioport: + ioport__unregister(kvm, 0x0070); +out_device: + device__unregister(&rtc_dev_hdr); + return r; } dev_init(rtc__init); -- 2.17.1 _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH kvmtool] rtc: Generate fdt node for the real-time clock 2020-05-14 9:45 [PATCH kvmtool] rtc: Generate fdt node for the real-time clock Andre Przywara @ 2020-05-14 12:20 ` Mark Rutland 2020-05-14 13:11 ` André Przywara 2020-05-19 16:46 ` Will Deacon 1 sibling, 1 reply; 4+ messages in thread From: Mark Rutland @ 2020-05-14 12:20 UTC (permalink / raw) To: Andre Przywara; +Cc: Sami Mujawar, Will Deacon, kvmarm, kvm Hi Andre, On Thu, May 14, 2020 at 10:45:53AM +0100, Andre Przywara wrote: > On arm and arm64 we expose the Motorola RTC emulation to the guest, > but never advertised this in the device tree. > > EDK-2 seems to rely on this device, but on its hardcoded address. To > make this more future-proof, add a DT node with the address in it. > EDK-2 can then read the proper address from there, and we can change > this address later (with the flexible memory layout). > > Please note that an arm64 Linux kernel is not ready to use this device, > there are some include files missing under arch/arm64 to compile the > driver. I hacked this up in the kernel, just to verify this DT snippet > is correct, but don't see much value in enabling this properly in > Linux. > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> With EFI at least, the expectation is that the RTC is accesses via the runtime EFI services. So as long as EFI knows about the RTC and the kernel knows about EFI, the kernel can use the RTC that way. It would be problematic were the kernel to mess with the RTC behind the back of EFI or vice-versa, so it doesn't make sense to expose voth view to the kernel simultaneously. I don't think it makes sense to expose this in the DT unless EFI were also clearing this from the DT before handing that on to Linux. If we have that, I think it'd be fine, but on its own this patch introduces a potnetial problem that I think we should avoid. Thanks, Mark. > --- > hw/rtc.c | 44 ++++++++++++++++++++++++++++++++++++++------ > 1 file changed, 38 insertions(+), 6 deletions(-) > > diff --git a/hw/rtc.c b/hw/rtc.c > index c1fa72f2..5483879f 100644 > --- a/hw/rtc.c > +++ b/hw/rtc.c > @@ -130,24 +130,56 @@ static struct ioport_operations cmos_ram_index_ioport_ops = { > .io_out = cmos_ram_index_out, > }; > > +#ifdef CONFIG_HAS_LIBFDT > +static void generate_rtc_fdt_node(void *fdt, > + struct device_header *dev_hdr, > + void (*generate_irq_prop)(void *fdt, > + u8 irq, > + enum irq_type)) > +{ > + u64 reg_prop[2] = { cpu_to_fdt64(0x70), cpu_to_fdt64(2) }; > + > + _FDT(fdt_begin_node(fdt, "rtc")); > + _FDT(fdt_property_string(fdt, "compatible", "motorola,mc146818")); > + _FDT(fdt_property(fdt, "reg", reg_prop, sizeof(reg_prop))); > + _FDT(fdt_end_node(fdt)); > +} > +#else > +#define generate_rtc_fdt_node NULL > +#endif > + > +struct device_header rtc_dev_hdr = { > + .bus_type = DEVICE_BUS_IOPORT, > + .data = generate_rtc_fdt_node, > +}; > + > int rtc__init(struct kvm *kvm) > { > - int r = 0; > + int r; > + > + r = device__register(&rtc_dev_hdr); > + if (r < 0) > + return r; > > /* PORT 0070-007F - CMOS RAM/RTC (REAL TIME CLOCK) */ > r = ioport__register(kvm, 0x0070, &cmos_ram_index_ioport_ops, 1, NULL); > if (r < 0) > - return r; > + goto out_device; > > r = ioport__register(kvm, 0x0071, &cmos_ram_data_ioport_ops, 1, NULL); > - if (r < 0) { > - ioport__unregister(kvm, 0x0071); > - return r; > - } > + if (r < 0) > + goto out_ioport; > > /* Set the VRT bit in Register D to indicate valid RAM and time */ > rtc.cmos_data[RTC_REG_D] = RTC_REG_D_VRT; > > + return r; > + > +out_ioport: > + ioport__unregister(kvm, 0x0070); > +out_device: > + device__unregister(&rtc_dev_hdr); > + > return r; > } > dev_init(rtc__init); > -- > 2.17.1 > > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH kvmtool] rtc: Generate fdt node for the real-time clock 2020-05-14 12:20 ` Mark Rutland @ 2020-05-14 13:11 ` André Przywara 0 siblings, 0 replies; 4+ messages in thread From: André Przywara @ 2020-05-14 13:11 UTC (permalink / raw) To: Mark Rutland; +Cc: Sami Mujawar, Will Deacon, kvmarm, kvm On 14/05/2020 13:20, Mark Rutland wrote: Hi, > > On Thu, May 14, 2020 at 10:45:53AM +0100, Andre Przywara wrote: >> On arm and arm64 we expose the Motorola RTC emulation to the guest, >> but never advertised this in the device tree. >> >> EDK-2 seems to rely on this device, but on its hardcoded address. To >> make this more future-proof, add a DT node with the address in it. >> EDK-2 can then read the proper address from there, and we can change >> this address later (with the flexible memory layout). >> >> Please note that an arm64 Linux kernel is not ready to use this device, >> there are some include files missing under arch/arm64 to compile the >> driver. I hacked this up in the kernel, just to verify this DT snippet >> is correct, but don't see much value in enabling this properly in >> Linux. >> >> Signed-off-by: Andre Przywara <andre.przywara@arm.com> > > With EFI at least, the expectation is that the RTC is accesses via the > runtime EFI services. So as long as EFI knows about the RTC and the > kernel knows about EFI, the kernel can use the RTC that way. Yes, this is how it works at the moment. > It would be > problematic were the kernel to mess with the RTC behind the back of EFI > or vice-versa, so it doesn't make sense to expose voth view to the > kernel simultaneously. Agreed. > I don't think it makes sense to expose this in the DT unless EFI were > also clearing this from the DT before handing that on to Linux. If we > have that, I think it'd be fine, but on its own this patch introduces a > potnetial problem that I think we should avoid. Yes, removing or at least disabling the node was the plan, but first we need to convince EDK-2 to actually use it first ;-) At the moment the addresses are hardcoded, and things look fine, but we want (and need to) become more flexible with the memory map, so just relying on 0x70/0x71 doesn't have a future. Especially this low memory areas already has problems. From a kvmtool's perspective this "two users problem" shouldn't matter, though, that's a problem that EDK-2 needs to solve, if it chooses to use the RTC in its runtime. And as mentioned: right now Linux can't use the Motorola RTC driver on arm64, so there is no danger atm that the kernel picks the device up and uses it. But I would rather sooner than later let EDK-2 use the DT address, before this hardcoded address usage becomes to widespread to be ignored. And yes, I will push for disabling the DT node then in EDK-2. Cheers, Andre. >> --- >> hw/rtc.c | 44 ++++++++++++++++++++++++++++++++++++++------ >> 1 file changed, 38 insertions(+), 6 deletions(-) >> >> diff --git a/hw/rtc.c b/hw/rtc.c >> index c1fa72f2..5483879f 100644 >> --- a/hw/rtc.c >> +++ b/hw/rtc.c >> @@ -130,24 +130,56 @@ static struct ioport_operations cmos_ram_index_ioport_ops = { >> .io_out = cmos_ram_index_out, >> }; >> >> +#ifdef CONFIG_HAS_LIBFDT >> +static void generate_rtc_fdt_node(void *fdt, >> + struct device_header *dev_hdr, >> + void (*generate_irq_prop)(void *fdt, >> + u8 irq, >> + enum irq_type)) >> +{ >> + u64 reg_prop[2] = { cpu_to_fdt64(0x70), cpu_to_fdt64(2) }; >> + >> + _FDT(fdt_begin_node(fdt, "rtc")); >> + _FDT(fdt_property_string(fdt, "compatible", "motorola,mc146818")); >> + _FDT(fdt_property(fdt, "reg", reg_prop, sizeof(reg_prop))); >> + _FDT(fdt_end_node(fdt)); >> +} >> +#else >> +#define generate_rtc_fdt_node NULL >> +#endif >> + >> +struct device_header rtc_dev_hdr = { >> + .bus_type = DEVICE_BUS_IOPORT, >> + .data = generate_rtc_fdt_node, >> +}; >> + >> int rtc__init(struct kvm *kvm) >> { >> - int r = 0; >> + int r; >> + >> + r = device__register(&rtc_dev_hdr); >> + if (r < 0) >> + return r; >> >> /* PORT 0070-007F - CMOS RAM/RTC (REAL TIME CLOCK) */ >> r = ioport__register(kvm, 0x0070, &cmos_ram_index_ioport_ops, 1, NULL); >> if (r < 0) >> - return r; >> + goto out_device; >> >> r = ioport__register(kvm, 0x0071, &cmos_ram_data_ioport_ops, 1, NULL); >> - if (r < 0) { >> - ioport__unregister(kvm, 0x0071); >> - return r; >> - } >> + if (r < 0) >> + goto out_ioport; >> >> /* Set the VRT bit in Register D to indicate valid RAM and time */ >> rtc.cmos_data[RTC_REG_D] = RTC_REG_D_VRT; >> >> + return r; >> + >> +out_ioport: >> + ioport__unregister(kvm, 0x0070); >> +out_device: >> + device__unregister(&rtc_dev_hdr); >> + >> return r; >> } >> dev_init(rtc__init); >> -- >> 2.17.1 >> >> _______________________________________________ >> kvmarm mailing list >> kvmarm@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH kvmtool] rtc: Generate fdt node for the real-time clock 2020-05-14 9:45 [PATCH kvmtool] rtc: Generate fdt node for the real-time clock Andre Przywara 2020-05-14 12:20 ` Mark Rutland @ 2020-05-19 16:46 ` Will Deacon 1 sibling, 0 replies; 4+ messages in thread From: Will Deacon @ 2020-05-19 16:46 UTC (permalink / raw) To: Julien Thierry, Andre Przywara Cc: kvm, catalin.marinas, Sami Mujawar, Will Deacon, kvmarm On Thu, 14 May 2020 10:45:53 +0100, Andre Przywara wrote: > On arm and arm64 we expose the Motorola RTC emulation to the guest, > but never advertised this in the device tree. > > EDK-2 seems to rely on this device, but on its hardcoded address. To > make this more future-proof, add a DT node with the address in it. > EDK-2 can then read the proper address from there, and we can change > this address later (with the flexible memory layout). > > [...] Applied to kvmtool (master), thanks! [1/1] rtc: Generate fdt node for the real-time clock https://git.kernel.org/will/kvmtool/c/5a3a5c07dd87 Cheers, -- Will https://fixes.arm64.dev https://next.arm64.dev https://will.arm64.dev _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-05-19 16:47 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-14 9:45 [PATCH kvmtool] rtc: Generate fdt node for the real-time clock Andre Przywara 2020-05-14 12:20 ` Mark Rutland 2020-05-14 13:11 ` André Przywara 2020-05-19 16:46 ` Will Deacon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).