docs/system/arm/virt.rst | 1 + hw/arm/Kconfig | 1 + hw/arm/virt.c | 47 ++++++++++++++++++++++++++++++++++++++++ include/hw/arm/virt.h | 2 ++ 4 files changed, 51 insertions(+)
This patch adds timer peripherals to the arm-virt machine. The use case is, that this machine is quite useful for testing purposes when it comes to non-Linux operating system (seL4 in our case). However, is currently lacks a dedicates timer peripheral, so some scenarios cannot be tested easily with QEMU. The RTC cannot be used, because he resolution is too low. Since the sp804 supposed already exists in QEMU, adding these peripherals seems easy and it does not appear to break any existing use cases. Axel Heider (1): hw/arm/virt: add 2x sp804 timer docs/system/arm/virt.rst | 1 + hw/arm/Kconfig | 1 + hw/arm/virt.c | 47 ++++++++++++++++++++++++++++++++++++++++ include/hw/arm/virt.h | 2 ++ 4 files changed, 51 insertions(+) -- 2.34.5
On Wed, 30 Nov 2022 at 18:56, ~axelheider <axelheider@git.sr.ht> wrote: > > This patch adds timer peripherals to the arm-virt machine. The > use case is, that this machine is quite useful for testing purposes > when it comes to non-Linux operating system (seL4 in our case). > However, is currently lacks a dedicates timer peripheral, so some > scenarios cannot be tested easily with QEMU. The RTC cannot be > used, because he resolution is too low. Since the sp804 supposed > already exists in QEMU, adding these peripherals seems easy and > it does not appear to break any existing use cases. Is there a reason you can't use the CPU's built-in generic timer device ? That is what typical guest code does on this system. I'm a bit reluctant to add more devices to the virt board because over time it gradually gets increasingly complicated, and every new device model we expose to the guest is another thing that's part of the security attack surface for guest code trying to escape from a KVM VM. thanks -- PMM
Peter, >> This patch adds timer peripherals to the arm-virt machine.>> > Is there a reason you can't use the CPU's built-in generic timer > device ? That is what typical guest code does on this system. > I'm a bit reluctant to add more devices to the virt board > because over time it gradually gets increasingly complicated, > and every new device model we expose to the guest is another > thing that's part of the security attack surface for guest > code trying to escape from a KVM VM. For the seL4 specific case, this is currently not possible in the standard configuration. It's only exposed for a special debug and benchmarking configuration. The catch we have here is, that the virt machine is a nice generic ARM (and RISC-V) machine for OS testing purposes also, but it sometimes lacks things (see my other patched for the UART). So, I wonder what would be the best option to continue here. Should we consider defining another generic machine profile that is more suited for the system emulation use case. This is what OS developer could use then. Or could the virt machine get some config parameters to customize it further. So the "Machine-specific options" would support a "sp804=on" that would add two timer peripherals then? The really cool customization option would be passing a DTB to QEMU that describes exactly what "virt" machine is to be emulated. I think the Xlinx fork used to support this feature partly. Not sure if there was ever an attempt to mainline this? But it would avoid running into a command parameters hell for customization options. Axel
On Thu, 8 Dec 2022 at 16:59, Axel Heider <axelheider@gmx.de> wrote: > > Peter, > > >> This patch adds timer peripherals to the arm-virt machine.>> > > Is there a reason you can't use the CPU's built-in generic timer > > device ? That is what typical guest code does on this system. > > I'm a bit reluctant to add more devices to the virt board > > because over time it gradually gets increasingly complicated, > > and every new device model we expose to the guest is another > > thing that's part of the security attack surface for guest > > code trying to escape from a KVM VM. > > For the seL4 specific case, this is currently not possible in > the standard configuration. It's only exposed for a special > debug and benchmarking configuration. It's not clear to me what you mean here -- the generic timer in the CPU exists in all configurations, so there should be no obstacle to seL4 using it. > The catch we have here is, that the virt machine is a nice > generic ARM (and RISC-V) machine for OS testing purposes also, > but it sometimes lacks things (see my other patched for the > UART). So, I wonder what would be the best option to continue > here. Should we consider defining another generic machine > profile that is more suited for the system emulation use case. > This is what OS developer could use then. Or could the virt > machine get some config parameters to customize it further. > So the "Machine-specific options" would support a "sp804=on" > that would add two timer peripherals then? > > The really cool customization option would be passing a DTB > to QEMU that describes exactly what "virt" machine is to be > emulated. This is a firm "no" -- it sounds on the surface like a good idea but it doesn't actually work in practice -- DTB files don't provide enough info to be able to build a board from, except in some specific restricted situations like the Xilinx one. -- PMM
Peter, >> For the seL4 specific case, this is currently not possible in >> the standard configuration. It's only exposed for a special >> debug and benchmarking configuration. >> > It's not clear to me what you mean here -- the generic > timer in the CPU exists in all configurations, so there > should be no obstacle to seL4 using it. Access is not exposed to userland in the standard configuration and the standard kernel API has no no timeouts besides zero and infinite. It's a design thing in the end. Nothing that could not be hacked around or be changed in the design in the long run. But my goal is not to hack around, but have a "proper" machine simulation instead. Which basically falls down to having a generic machine in mainline that has a few more customization options. >> The really cool customization option would be passing a DTB >> to QEMU that describes exactly what "virt" machine is to be >> emulated. > > This is a firm "no" -- it sounds on the surface like a good > idea but it doesn't actually work in practice -- DTB files > don't provide enough info to be able to build a board from, > except in some specific restricted situations like the Xilinx > one. I can see the point. But what about supporting an overlay DTB that takes a stripped down virt machine as base? This might avoid some limitation. In the long run, customization via a DTB seems still better then adding parameters to the command line. For the short term, a few more command line options seem good enough. What is the general feeling about having a more general system emulation option when it comes to the "virt" machine, and a way of resolving the usage (and security) conflict with the KVM usecase. Axel
On Thu, 8 Dec 2022 at 17:25, Axel Heider <axelheider@gmx.de> wrote: > >> For the seL4 specific case, this is currently not possible in > >> the standard configuration. It's only exposed for a special > >> debug and benchmarking configuration. > >> > > It's not clear to me what you mean here -- the generic > > timer in the CPU exists in all configurations, so there > > should be no obstacle to seL4 using it. > > Access is not exposed to userland in the standard configuration > and the standard kernel API has no no timeouts besides zero and > infinite. It's a design thing in the end. Nothing that could not > be hacked around or be changed in the design in the long run. But > my goal is not to hack around, but have a "proper" machine > simulation instead. Which basically falls down to having a generic > machine in mainline that has a few more customization options. So, my take on this is that I'm open to adding things to the virt board where we don't provide a feature that's useful to guest code. The second UART falls in this category: it lets you do things that you otherwise could not do (like have one UART for firmware and one for a kernel). On the other hand, this case with the sp804 sounds more like QEMU is already providing functional timer facilities and the problem is on the guest software side. To me the "non-hacky" solution sounds like it is "sel4 should provide a better timer related API to userland". I don't really want to work around guest OS deficiencies in QEMU. thanks -- PMM
© 2016 - 2024 Red Hat, Inc.