IRC channel logs

<damo22>hi

<solid_black>hi damo22

<damo22>i think git-send-email is adding "Content-Transfer-Encoding: quoted-printable"

<damo22>but i cant find its script

<solid_black>it's in /libexec/git-core/git-send-email here

<damo22> transferEncoding = 8bit

<damo22>that should work

<damo22>ok i think it should be fixed

<damo22>Add this to .gitconfig

<damo22>[sendemail]

<damo22> transferEncoding = 8bit

<solid_black>not that I know anything about email, but isn't it an issue with git-am if it fails to apply patches encoded in a standard-conforming way (moreover, the one that git's own tooling emits)?

<damo22>i think its because Samuel prefers to read patches manually

<solid_black>it's content *transfer* encoding, no? shouldn't it be *decoded* before it tries to apply the patch?

<solid_black>same there, shouldn't your email client decode it before displaying it to the user?

<damo22>he probably reads them in plain text mbox format

<damo22>also why encode the message it should be displayed as written

<damo22>if i was on the receiving end of patches, i would want to be able to read them in vim

<damo22>just like the patch i sent

<solid_black>certainly it should be easy to view patches and edit them in vim and apply them; I'm not saying that it should not be

<etno>damo22: I have been trying to reproduce the "invalid FPU state" with qemu SMP on top of your latest fix-ioapic. I could not, but then I realized that you are doing this in x86_64. Is this correct?

<damo22>no

<damo22>i am using i386

<damo22>how are you launching qemu?

<damo22>etno: a lot of this is probably unnecessary, but i can share my qemu command:

<damo22>qemu-system-i386 -M q35,accel=kvm -m 4096 -smp 2 -net user,hostfwd=tcp::8888-:22 -net nic -curses -hda /dev/sda \

<damo22> -cpu Penryn,kvm=on,vendor=GenuineIntel,vmware-cpuid-freq=on,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check

<etno>qemu-system-i386 --accel tcg -m 1G -M q35 -smp 2 -s -S -drive format=raw,file=...

<damo22>the reason i use the cpu flags is because i am actually hosting it on amd cpu and i want to emulate a proper intel cpu

<etno>I am running on an Intel N4200

<damo22>what is tcg?

<etno>This is the jit recompiler accelerator. I need this for breakpoints to work, it seems

<damo22>thats neat

<etno>QEMU 5.2.0

<damo22>how does it compare in speed to kvm

<etno>Much slower, I would say

<etno>But for gnumach, it is not really an issue

<damo22>ok

<etno>I am worried that I made your life harder with this FPU patch...

<damo22>not at all

<damo22>its a simple revert if i need to

<damo22>but i dont understand it

<etno>If you want to take time, I can explain it. This may help to spot what could be wrong. As you like

<damo22>up to you

<damo22>you removed a cpuid instruction

<damo22>is that right?

<damo22>we are talking about commit f8d0f98e80b3 ?

<etno>Yes, because it was replacing the eax value we use further down

<etno>f8d0... yes

<etno>Here is the code, before: https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/i386/i386/fpu.c?id=eaa2f2c1bfe738d9a53c2f8ab9fbc96c2976f727#n180

<etno>Look at the eax test at 200

<etno>This is supposed to test cpuid (0xd,0x1) as at 180

<etno>But when the test with the panic message was inserted, it added a cpuid call with (0xd, 0x0) at 191

<youpi>the eax part is clearly wrong, yes

<youpi>one thing that gets different, though, is the ebx part

<youpi>we used to use ebx from the 0xd,0x1 cpuid

<youpi>for the offsetof computation

<youpi>while now we are using ebx from the 0xd,0x0 puid

<youpi>possibly it's something etno didn't realize would change

<youpi>I thought he noticed, but possibly not

<etno>One of the size checks was using the bitfield, instead of the flu state length

<etno>Fpu*

<youpi>? they're both using ebx

<youpi>either from 0xd,0x1 cpuid, or 0xd,0x0 cpuid

<damo22>the ebx cant be correct in both cases

<damo22>ie, before and after the change

<damo22>unless it was previously incorrect and your change fixes it

<youpi>the difference is IA32_XSS

<youpi>which we don't seem to be using

<youpi>damo22: you could try to restore

<youpi>+ fp_xsave_size = offsetof(struct i386_fpsave_state, xfp_save_state) + ebx;

<youpi>+

<youpi>+ if (fp_xsave_size < sizeof(struct i386_fpsave_state))

<youpi>+ panic("CPU-provided xstate size %d " etc.

<youpi>in the if (eax & CPU_FEATURE_XSAVES) { branch

<etno>I based my changes on p823 content: https://www.intel.fr/content/www/fr/fr/content-details/782158/intel-64-and-ia-32-architectures-software-developer-s-manual-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4.html

<damo22>fp_load: invalid FPU state!

<damo22>no panic

<damo22>im going to remove all my cpu flags

<damo22>that fixed it

<damo22>:\

<etno>youpi: should the size test be using (D,0)/ebx or (D,1)/ebx ? I must admit that I don't really understand the purpose of the test

<etno>Ohhhhhhh, it depends on the features ? That would make my patch partially wrong. And this is probably what you mean by "the difference is IA32_XSS", youpi

<etno>sneek: later tell youpi: I will try to issue a fix for the ebx misuse I introduced

<sneek>Got it.

<etno>damo22: could it be that, while the cpuid options in qemu are able to change what the guest sees returned by a CPUID call (trap and simulated), with KVM the instructions hit the actual CPU and then a mismatch occurs ?

<etno>Maybe with a fully emulated CPU, the features would match with the qemu options

<youpi>damo22: not sure what you tested, did the partial revert I suggested not work?

<sneek>Welcome back youpi, you have 1 message!

<sneek>youpi, etno says: I will try to issue a fix for the ebx misuse I introduced

<damo22>youpi: i tested your suggested change, it seemed to make no difference, but i removed all my -cpu flags in qemu and that fixed it

<damo22>however, etno says he thinks there is a problem with his change regarding ebx as well

<damo22>maybe i cannot emulate flags that do not exist in the host, but i did add "check" flag so that should tell me, no?

<youpi>it should tell you yes

<youpi>removing flags removes features and thus probably you simply don't hit the XSAVES case any more

<damo22>ok

<youpi>damo22: I guess if you disable the xsaves branch things work with all your flags?

<damo22>"disable the xsaves branch" i dont follow

<damo22>you mean remove the if

<youpi> if (eax & CPU_FEATURE_XSAVES) {

<youpi>put a && 0 here

<damo22>ok

<damo22>sorry i rebased master it will take a while to compile

<damo22>no it still occurs

<anatoly>solid_black: oh yeah, it booted

<damo22>youpi: +xsave,+xsaveopt

<damo22>these two flags probably break it

<solid_black>hi anatoly!

<solid_black>yay

<damo22>bugs : fxsave_leak

<solid_black>how far did it get? did I push the version that boots with OpenRC, or are you just booting with init=/bin/sh?

<anatoly>solid_black: I'm on older commit so tried only /bin/sh. Will rebuild tomorrow and try again

<solid_black>I should push my latest changes too

<anatoly>ok

<solid_black>I have tried building dde/netdde, but it doesn't succeed yet

<etno>youpi: I have difficulties understanding the check in init_fpu(). AIUI, fp_xsave_size is the size i386_fpsave_state should be to contain all of the FPU state. But the current code is making sure that fp_xsave_size is bigger or equal. I can make sense only of equality, because otherwise things would overflow the structure.

<youpi>etno: no, not all

<youpi>xsaves & co are precisely meant for the OS not to actually have to know ahead of runtime how much room will be needed

<youpi>the check is just there to make sure the value is not completely bogus

<etno>ACTION realizes suddenly that fp_xsave_size is not a local variable

<etno>youpi: thanks for the explanation

IRC channel logs

2024-02-08.log