IRC channel logs

***Out`Of`Control is now known as GNU[BDC]

***GNU[BDC] is now known as Viper

***Viper is now known as GNU[BDC]

<almuhs>damo22 youpi: I've got to find APIC table and lapic address. But, when I try to find the apic entries, all are shown as apic_id = 0

<almuhs>check this: https://pasteboard.co/J6q6QRD.png

<almuhs>maybe apic table not fill in a single page?

***Server sets mode: +nt

<almuhs>this is the video https://www.youtube.com/watch?v=uZ3BVMdvEbQ&feature=youtu.be

<youpi>almuhs: I'm not surprised that the first CPU has APIC ID 0

<almuhs>other question is that my VM has 4 cores

<almuhs>but gnumach only detects one of this

<almuhs>youpi: I've printed ncpu and nioapic values, and both has the value 1

<almuhs>but my VM is 4 cores

<almuhs>I've just printed the end address of apic table https://pasteboard.co/J6qG0Pf.png

<almuhs>apic table start is in f9494000 and the end is in f949364d

<damo22>hi

<almuhs>hi

<damo22>how did you start qemu

<almuhs>with this script https://gist.github.com/AlmuHS/73bae6dadf19b0482a34eaab567bfdfa

<damo22>not sure if coreduo has smp4

<almuhs>anyways, if qemu takes coreduo, It might shows 2 cpus

<almuhs>but, in qemu monitor, "info cpus" shows 4 cpus

<damo22>The following CPUs models are compatible with most AMD and Intel x86

<damo22>hosts, but their usage is discouraged, as they expose a very limited

<damo22>featureset, which prevents guests having optimal performance.

<damo22>coreduo...

<almuhs>I've just removed this line, but the problem is the same

<almuhs>gnumach only find 1 cpu

<damo22>-M q35,accel=kvm

<damo22>it might not have the correct tables otherwise

<almuhs>what is this?: <damo22> -M q35,accel=kvm

<damo22>append that to your qemu command

<almuhs>kvm is enabled

<almuhs>-enable-kvm

<damo22>im not sure if that flag works as expected

<almuhs>what is q35?

<damo22>q35 is the chipset

<youpi>err

<damo22>it changes the machine layout

<youpi>qemu's cpu emulation is completely independent from the numer of smp CPU

<youpi>you need to pass -smp 2 to have two CPUs

<youpi>whatever the kind of CPU you as to simulation

<youpi>s/as/ask

<almuhs>I have -smp 4

<damo22>ok but the acpi tables might not get generated unless its the right "machine"

<youpi>I have never had to do anything beyond -smp <n> to get smp support

<almuhs>in the MinSMP the 4 cpus are find correctly

<damo22>ok then

<almuhs>youpi: then, how you set the number of cpus in qemu?

<damo22>-smp N

<almuhs>It's the same than me

<damo22>maybe theres something wrong with your parser

<damo22>does it stop when it finds one entry?

<almuhs>nope

<almuhs>but I suspect that maybe the table doesn't fills in a single page

<almuhs>or It is wrongly mapped

<almuhs>this is the code https://github.com/AlmuHS/GNUMach_SMP/blob/smp-new/i386/i386at/acpi_parse_apic.c#L280

<almuhs>this was the original code: https://github.com/AlmuHS/GNUMach_SMP/blob/smp/i386/i386at/acpi_rsdp.c

<damo22> https://github.com/AlmuHS/GNUMach_SMP/blob/smp-new/i386/i386at/acpi_parse_apic.c#L262 what is "acpi_rsdt_n"

<almuhs>the number of entries in rsdt table

<damo22>i thought the madt table has different entries for the cpus not the rsdt

<almuhs>yes, the madt parser is below

<almuhs>in acpi_apic_setup()

<almuhs>this line is only where the apic table is found (inside rsdt table)

<damo22>ok so it "found apic in address"

<damo22>?

<almuhs>because I found the main address of MADT table

<almuhs>aka APIC table

<almuhs>the pointer to MADT table is inside of RSDT table

<damo22>i think "end" is not the end of the madt table

<damo22>uint32_t end = (uint32_t) apic + apic->header.length;

<damo22>is that the total length?

<almuhs>check the while loop

<almuhs> while((uint32_t)apic_entry < end){

<almuhs>so, this end might be the end of madt table

<damo22>if((lapic_entry->flags & 0x1) && ncpu < NCPUS){ <--- did you set NCPUS?

<almuhs>oops... this can be the error

<almuhs>NCPUS is set to 1 yet

<damo22>just take out the &&

<almuhs>where is this line?

<damo22>you dont need a check for that

<damo22>331

<almuhs>yes

<almuhs>I've removed It. I go to check It

<damo22>you will only have 1 ioapic

<damo22>thats pretty normal

<almuhs>yes, It very common

<almuhs>**It's

<almuhs>but we might consider that could be more than one

<almuhs>oops: https://pasteboard.co/J6qZfem.png

<almuhs>something goes wrong

<almuhs>the code is here: https://github.com/AlmuHS/GNUMach_SMP/blob/smp-new/i386/i386at/acpi_parse_apic.c#L280

<almuhs>but the lapic and ioapics are found correctly https://pasteboard.co/J6r1gm2.png

<almuhs>oh... I know the reason. The cpu_to_lapic array has defined its size using NCPUS

<almuhs>so, in the print loop, this exceed this range

<almuhs>yes, this is the reason

<almuhs>by now, I have defined the size of cpu_to_lapic array in 255

<almuhs>damo22: now It works https://pasteboard.co/J6r5m7W.png

<almuhs>:-)

<damo22>ok

<almuhs>now I have to clean the code to remove useless prints

<damo22> https://github.com/zamaudio/GNUMach_SMP/blob/feat-ioapic/i386/i386at/ioapic.c <--- this configures most of the ioapic

<damo22>but needs to be integrated with the madt overrides for the irqs

<almuhs>do you need access to madt?

<damo22>yes

<almuhs>then I will move apic pointer output of acpi_setup

<almuhs>as a global

<damo22>yep

<damo22>maybe call it madt not apic

<almuhs>apic_madt ?

<almuhs>damo22: now you can find the pointer here https://github.com/AlmuHS/GNUMach_SMP/blob/smp-new/i386/i386at/acpi_parse_apic.c#L31

<almuhs>by default is defined to zero, like NULL value

<almuhs>damo22: the booting process recording https://www.youtube.com/watch?v=huticmoqPpQ&feature=youtu.be

<almuhs>but, if I saw It well, the APIC is found after harddisk starts

<almuhs>then, will can you to configure IOAPIC without problems?

<almuhs>ok, all pushed to github

<damo22>i think i will need to configure the ioapic in gnumach

<damo22>because i need to swap pic for apic

<damo22>but it should be done after SMP work

<almuhs>yes, but you told that the configuration must be before load harddisk drivers

<almuhs>**must be done

<damo22>i think we can leave the ioapic work for later

<almuhs>and, currently the apic parser call is done just after harddisk drivers loading

<almuhs>I'm asking about might be better to move the acpi_setup() call to a previous line

<damo22>we can move it around later as required, also disks will be done in userspace with rump

<almuhs>then, the current call is not a problem, is not?

<damo22>should be fine

<almuhs>ok

<almuhs>tomorrow I will have to work in naming

<almuhs>acpi_setup() is not a good name for a apic parser

<damo22>try to use GNU coding style

<damo22>or it may be hard to merge later

<almuhs>yes

<almuhs>maybe I can use a e-style plugin in GNU mode

<damo22>i gtg

<almuhs>ok, bye

<almuhs>I go to sleep

<almuhs>4:00 AM in spain

<almuhs>bye

***wleslie_ is now known as wleslie

***pie_[bnc] is now known as pie_

<almuhs>hi. Tonight we got to find all lapic and ioapic from gnumach. But, before send the patch, I want to improve the code

<almuhs>by example, I want to rename this function, to a more appropriate name https://github.com/AlmuHS/GNUMach_SMP/blob/smp-new/i386/i386at/acpi_parse_apic.c#L77

<almuhs>what name do you suggest to this function?

<almuhs>this function start the search of MADT table, and generates two structures with the APIC ID of each cpu and ioapic existent in the machine

IRC channel logs

2020-05-02.log