diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/gemma3:12b/device/1716 | 10 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/device/1716132 | 21 |
2 files changed, 31 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/device/1716 b/results/classifier/gemma3:12b/device/1716 new file mode 100644 index 00000000..92be1f5d --- /dev/null +++ b/results/classifier/gemma3:12b/device/1716 @@ -0,0 +1,10 @@ + +Cannot raise low memory using max-ram-below-4g on current i440fx +Description of problem: +We have a use case where we have a virtual machine with at least 8 Gb of RAM and at least 3.5Gb of it in the low memory. However, I could not achieve it this far with QEMU, only on the deprecated i440fx 1.7 architecture. The size of lowmem is never greater than 3 Gb, except if I assign memory to the vm between 3 Gb and 3.5 Gb. If I go even a slightly above 3.5 Gb then it falls back to 3 Gb. + +I did some research and I found the source file hw/i386/pc_piix.c. There is a piece of code which is responsible for setting the low memory at the beginning of function pc_init1(). It seems that the problem lies in the property `gigabyt_align` of all i440fx architectures newer than 1.7. The comment which explains this piece of code does not mention at all that raising lowmem does not work on newer pc architectures. According to the comments setting the size of lowmem based of the `max-ram-below-4g` option should happen before the gigabyte alignment, not after it. Anyway, it does not make sense because with default being 3 Gb gigabyte alignment always means 3 Gb so raising is not possible at all. The last example of the comment clearly states that raising should be possible using the newest `pc` architecture: `qemu -M pc,max-ram-below-4g=4G -m 3968M -> 3968M low (=4G-128M)`. However, according to the code below the comment this is not the way it works because gigabyte alignment happens after. + +To solve the problem there are two possibilities: if this is a bug then the solution is obvious, the gigabyte aligment should happen before applying the `max-ram-below-4g` option. If this is not a bug but the expected way of working then there could be an option to override the `gigabyte_align` attribute from command line. + +What do you think? diff --git a/results/classifier/gemma3:12b/device/1716132 b/results/classifier/gemma3:12b/device/1716132 new file mode 100644 index 00000000..f38fb908 --- /dev/null +++ b/results/classifier/gemma3:12b/device/1716132 @@ -0,0 +1,21 @@ + +Win 10 bitlocker won't initialise pass-through TPM + +All stock Ubuntu Zesty, Win10Pro KVM guest configured with OVMF and Q35. My host has an ASRock Z97 Extreme 6 board with a TPM header which is populated with v1.2 complaint device. + +Testing in my host the TPM device is function, I can tpm_takeownership and tpm_clear successfully and similar testing by passing the device through to a linux guest also succeeds. + +However using Bitlocker in Windows 10 Pro release 1703 Windows advises it cannot "Prepare" the device which I take to mean it cannot take ownership of it. I believe this to be related to Windows inability to view the TCG Event Log which is evidenced in the below 2 screencaps, however I'm no expert. + +https://s26.postimg.org/vter35eh5/Screenshot_20170907_114644.png +https://s26.postimg.org/klo854qyx/Screenshot_20170909_143841.png + +I've also tested the scenario with qemu 2.10 which provided the exact same results. The only difference in the test setup is that I had to make the guest boot with SeaBios instead of OVMF. (Windows wouldn't boot with OVMF with the boot manager giving me an error pointing to a BCD issue. Researching this it seemed related to an old ACPI problem, I believe this unrelated to my TPM issue so will do more research and raise a separate bug for this if needed.) + +Happy to provide further configurations and build logs as necessary so please advise me what is needed. + +Lastly for background reading. I've been trying to get TPM passthrough working with Windows for a long time now and have hit several different issues which I believe have been addressed by both code maturity in Qemu but also in Windows releases. An earlier bug report can be found here (https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1615722) which concludes advising me to raise this new/separate issue. + +Thanks in advance, + +Kelvin \ No newline at end of file |