diff options
Diffstat (limited to 'results/classifier/zero-shot/118/files/1917940')
| -rw-r--r-- | results/classifier/zero-shot/118/files/1917940 | 68 |
1 files changed, 68 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/files/1917940 b/results/classifier/zero-shot/118/files/1917940 new file mode 100644 index 000000000..a743cbbad --- /dev/null +++ b/results/classifier/zero-shot/118/files/1917940 @@ -0,0 +1,68 @@ +architecture: 0.952 +x86: 0.951 +files: 0.935 +user-level: 0.907 +performance: 0.902 +semantic: 0.894 +device: 0.886 +boot: 0.848 +graphic: 0.822 +mistranslation: 0.752 +permissions: 0.742 +debug: 0.732 +hypervisor: 0.669 +peripherals: 0.651 +PID: 0.632 +assembly: 0.625 +register: 0.612 +network: 0.609 +ppc: 0.607 +arm: 0.601 +kernel: 0.577 +i386: 0.555 +risc-v: 0.513 +virtual: 0.512 +KVM: 0.509 +socket: 0.496 +TCG: 0.479 +VMM: 0.467 +vnc: 0.461 + +-bios edk2-$arch-code doesn't work for x86 + +Whilst creating a flash device is recommended, -bios <file> is extremely useful in many cases as it automatically searches $PREFIX/share/qemu rather than requiring the caller (be it a human or a script) to work out where that directory is for the QEMU being called and prepend it to the file name. + +Currently, all the x86 EDK2 FD code files are 3653632 bytes in size, or 0x37c000 bytes. However, for some reason I cannot find the answer to (I traced the code back to 7587cf44019d593bb12703e7046bd7738996c55c), x86's -bios only allows files that are multiples of 64K in size (x86_bios_rom_init), which would require the EDK2 ROMs to be rounded up to 0x380000 bytes. If I delete the check, QEMU is able to load the only-16K-multiple-sized EDK2 and boot an OS just fine. If I pad EDK2 with 16K of zeroes at the *start* (since the ROM gets mapped counting backwards), it also works just fine (but padding at the *end* doesn't). Please therefore either relax the check in x86_bios_rom_init or ensure the EDK2 binary is suitably padded. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + |