clock isn't normalized if not running on kvm about nanos HOT 11 CLOSED

@convolvatron
Could you clarify that i understood right.
You wish that we use HPET directly.
I first step we need checked ACPI table (I can't find this functionality)
After that use data from this record make usable system HPET timer.
And i should do provide this feature.
Is it correct?

from nanos.

currently what clock support we have is based on rdtsc. unfortunately there isn't any way to reliably correlate rdtsc values to actual clock seconds. one standard approach is to use the 'real time clock' in io space to check to see how fast rdtsc is running and adapt it. this is a bit painful and not very accurate (although for our purposes probably good enough)

the real problem is that, especially in a virtual environment, rdtsc can stop for periods and change its rate

kvm has a cute little model where if you set an msr, it just tells you what the scaling factor and offset should be, and updates it when you go to sleep. this isn't a standard. currently kvm clock scaling plus rdtsc is our only working clock.

an hpet driver would help, because its supposed to be pinned to a fixed frequency clock, and unlike the rtc is a high enough frequency to run sub-ms events off of.

hpet is ostensibly linked to acpi for discovery, but when I looked into this my understanding was that its just sitting in a well known place in memory space just like everyone else. acpi is a giant mess. if it turns out to be mandatory for hpet use we should consider another clock source. i guess if there isn't a viable alternative we can try to port the minimum amount of acpi machinery necessary from freebsd...but its a whole thing.

from nanos.

I tried to find some reference to finding/changing the HPET base without using ACPI and failed, do you have an opinion as to whether it would be better to:

o use the PIT or RTC to calibrate RDTSC (or some other combination of clocks and references)
o implement/steal the minimum of ACPI necessary to find the HPET base

I would like to think there is some value in having the ACPI support aside from getting this one number...but I can't seem to think of anything.

if you choose to do clock calibration and are unsure about how to proceed we can discuss that and maybe I can try to find you a good reference. the summary there is just that slowly adjusting the scaling factor (rate) is a simple approach, can be made to be monotonic, and is reasonably robust.

one short term/incremental approach might be to tell qemu/kvm where to put the thing so we know where to look for it.

from nanos.

According to sources https://github.com/siemens/jailhouse/blob/master/configs/x86/qemu-x86.c
I will try to use this address
/* MemRegion: fed00000-fed003ff : PNP0103:00 (HPET) */
{
.phys_start = 0xfed00000,
.virt_start = 0xfed00000,
.size = 0x1000,
.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE,
},
But "I can try to find you a good reference." I will take with thanks.

from nanos.

But I should warn about such opportunities qemu-system-x86_64 --help | grep hpet
-no-hpet disable HPET

from nanos.

oh, good find. there has to be an msr to set this, but they've hidden it pretty well. apparently
some bioses stash that address in cmos and you can manually configure it.

but yeah, that address seems to be the default much like the lapic0 address

from nanos.

If my try is be successful I will add comment "TODO: We should be add reading ACPI for distinguish available HPET " because this is only one proper way...

from nanos.

We checked several systems and HPET address is 0xfed00000 on all of them. So we can stick to it for now.

from nanos.

The link to specification is https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/software-developers-hpet-spec-1-0a.pdf

from nanos.

@convolvatron @wjhun
Can you explain me how i can map physical memory?
I did memory allocation from virtual heap.
capabilities = allocate(backed_virtual, backed_virtual->pagesize);
Then i use function to map memory
map((u64)capabilities,HPET_TABLE_ADDRESS,1024,backed_virtual); // from /uniboot/x86_64/page.c
Where HPET_TABLE_ADDRESS is real address in physical memory.
The result not looks as true...
It looks as double alloc.

from nanos.

side note that William is working on a new interface for map

note that backed virtual allocates both a virtual address and maps a physical page behind it. this is currently kind of messed up and doesn't clear the TLB (page entry cache) on the processor (which is what William is fixing) when you remap the new entry.

so the first allocate you want to get a virtual range by allocating off some virtual heap (or, frankly for purposes of debugging you could identity-map HPET_TABLE_ADDRESS and leave an XXX)

then you want to map that virtual to the physical (HTA). mappings are 4k in size, so the third argument should be PAGESIZE. the last argument is the heap from which to draw memory for the page entries themselves, and always has to be 'pages', which should be stashed in the new kernel structure

from nanos.