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