On Wed, 2 Sep 2020 at 18:03, Philippe Mathieu-Daudé <f4...@amsat.org> wrote: > > On 9/2/20 6:49 PM, Peter Maydell wrote: > > On Wed, 2 Sep 2020 at 17:35, Philippe Mathieu-Daudé <f4...@amsat.org> wrote: > >> Peter said "'clock' is basically meaningless for virt machines", > >> > >> I understand and agree. But how to make that explicit/obvious in > >> the code, when a device expects a clock frequency/period? > > > > When a particular *device* needs a clock, then presumably > > it has a defined purpose for it, and we can pick a > > frequency for it then. > > > >> See for example hw/riscv/virt.c, it uses the following (confusing > >> to me) in virt_machine_init(): > >> > >> serial_mm_init(system_memory, memmap[VIRT_UART0].base, > >> 0, qdev_get_gpio_in(DEVICE(mmio_plic), UART0_IRQ), 399193, > >> serial_hd(0), DEVICE_LITTLE_ENDIAN); > > > > In this case, the board has a model of a 16550A UART on it, > > which uses its input clock to determine what the actual baud > > rate is for particular guest settings of the divisor registers. > > So we need to look at: > > * what does guest software expect the frequency to be? > > QEMU is supposed to model machine with no knowledge of the guest, > but the virt case is a particular one indeed... as it has to know > it is virtualized. > > > * what is a "good" frequency which gives the guest the best > > possible choices of baud rate? > > I'll think about it...
My guess is that guest code assumes "same frequency an x86 PC uses", but a risc-v person might know better... (For QEMU I think it only makes a visible difference when you pass a host serial port through to the guest as otherwise we ignore whatever baud rate the guest sets.) thanks -- PMM