Looking glass VM to VM not working

Operating Systems & Open Source Looking Glass
,
1

Hi,
I’m trying to use looking glass VM to VM but I can’t get it to work. One thing that I don’t understand and I haven’t found in the documentation is how do I setup the kvmfr module between the VM host and the VM linux client.
Right now i have built the kvmfr module for the host, and from the host I can run looking glass and connect to the windows VM. However when I try to connect to the windows VM from the Linux VM the client doesn’t connect to the windows VM and waits forever.
I inserted the command line parameters as described here IVSHMEM with the KVMFR module (Recommended) — Looking Glass B7 documentation but in the linux VM the /dev/kvmfr0 doesn’t show up until I load the module in the VM. But then it can’t connecto to the windows VM.

Can someone explain me where I should be building and loading the KVMFR module and which parameter I have to pass to the client VM?

Thanks
Andrea

1 Like
2

Hi,
I’m having the same issue with the error

kvmfr: kvmfr_pci_probe: failed to remap pages! ret = -22

Can you please elaborate on the “set the CPU host max physical bits in QEMU to limit the upper address range” ? I guess you’re referring to the host-phys-bits-limit=bits option as explained here: physical address space in qemu | 🇺🇦 kraxel’s news , but which value should I set?
In my system I have, both on the host and in the VM guest the following:

Address sizes:                        52 bits physical, 57 bits virtual

qemu 9.2, kernel 6.11.0-19-generic, Ubuntu
Thanks for your help,
Andrea

Looking glass B6 and B7 rc1, not working with new kernels
3

Hi Andrea,

The problem is as mentioned on GitHub, you have set the max physical bits too high for the IVSHMEM’s memory to be placed by the guest in a region that the kernel can map for usage.

You need to reduce the number of bits presented to the guest to a value that is suitable for your CPU. AMD is commonly 40, where Intel is commonly 39, you will simply need to experiment to discover what works for you as it’s CPU model specific.

For example:

<cpu mode='host-passthrough' migratable='off'>
  <cache mode='passthrough'/>
  <maxphysaddr mode='passthrough' limit='39'/>
</cpu>

The only negitive impact that reducing this value has is reducing the amount of physical ram the guest can make use of. With 39 bits you can still address up to 512GB of RAM (2 pow 39 = 549755813888). Unless you’re giving your guest > 0.5TB of RAM, there will be no issues.

4

Hi,

Thank you for the answer; what I don’t understand is why the physical bits are set to that value: where does the kernel (or other piece of code) gets that value, and why it’s not the correct one?
I didn’t set anything and I repeat that I have a value of 52 for physical address size also on the VM host system - the CPU is a threadripper 7960x.

Bye
Andrea

5

It’s from the CPU itself, QEMU is simply passing it through to report what the host CPU has. Unfortunatly it breaks out usage scenario.

There is no detrimental impact to reducing it, it does not impact performance, etc.

6

Looking through my feed I just realized why this thread didn’t get much attention. It had been posted into the wrong category on the forum.

If you need help in the future please be sure you post it here in future.

I have moved this thread to the correct category now.

2 Likes
7

Thanks for the explanation. So if I understand it correctly the 52 bits reported by the CPU is right but the value is too high and breaks some scenarios, is that so? If that’s the case maybe this should be explained somewhere in the documentation together with the solution, so that people won’t fall into this problem in the future.

Bye
Andrea

8

VM to VM usage configurations of Looking Glass are exceedingly rare, it’s simply been overlooked in the documentation. Added to my list to get this in there, thanks for the suggestions.

2 Likes