Missing PVR setting capability
Dear Qemu list members, I'm attempting to enable KVM in a Qemu-based project that is running on a T4240RDB board. After compiling my code with the -enable-kvm option I ran the qemu executable with the -enable-kvm option. The application exited with the following error message: "kvm error: missing PVR setting capability." What are some possibilities causing this error? *Wayne Z. Li* *The Boeing Company* | BT&E ESSI Midwest Software Tools & Modeling | St. Louis Cell: (801) 691-4098 * | *wayne.z...@boeing.com
Re: Missing PVR setting capability
If I run "lsmod | grep kvm" nothing shows up but if I just do a "find .
-name "kvm"" I get the following:
./usr/src/kernel/Documentation/virtual/kvm
./usr/src/kernel/arch/arm/kvm
./usr/src/kernel/arch/arm64/kvm
./usr/src/kernel/arch/mips/kvm
./usr/src/kernel/arch/powerpc/kvm
./usr/src/kernel/arch/s390/kvm
./usr/src/kernel/arch/tile/kvm
./usr/src/kernel/arch/x86/kvm
./usr/src/kernel/drivers/s390/kvm
./usr/src/kernel/include/config/kvm
./usr/src/kernel/include/config/have/kvm
./usr/src/kernel/include/kvm
./usr/src/kernel/virt/kvm
./dev/kvm
./sys/devices/virtual/misc/kvm
./sys/class/misc/kvm
./sys/kernel/debug/kvm
./sys/module/kvm
I guess this shows my OS does have KVM on it? I added the two flags you
mentioned when running QEMU (the -cpu and the -machine flags) but the -cpu
flag doesn't seem like it's doing anything as even when I put a clearly
wrong argument after the flag no error related to the cpu is thrown. Also
it says ppce500 is not a machine type and that the supported machines are:
bamboo bamboo
boeing-machine Boeing Machine
none empty machine
ref405ep ref405ep
taihutaihu
virtex-ml507 Xilinx Virtex ML507 reference design
The one being used right now is boeing-machine which is clearly specific to
the project I am working on. I'm not exactly sure what boeing-machine
refers to but I'll ask the person who wrote the code that specified that
machine,
On Tue, Oct 22, 2019 at 2:04 AM Thomas Huth wrote:
> On 21/10/2019 23.06, Wayne Li wrote:
> > Dear Qemu list members,
> >
> > I'm attempting to enable KVM in a Qemu-based project that is running on
> > a T4240RDB board. After compiling my code with the -enable-kvm option I
> > ran the qemu executable with the -enable-kvm option. The application
> > exited with the following error message: "kvm error: missing PVR setting
> > capability." What are some possibilities causing this error?
>
> That's an e6500 bas PPC board, isn't it? ... I guess nobody has been
> running KVM on such a system in a while...
>
> What do you get when running "lsmod | grep kvm" ? How did you run QEMU?
> I think you have to make sure to run with the right CPU model ("-cpu
> e6500") and machine (likely "-M ppce500" ?).
>
> Thomas
>
>
Re: Missing PVR setting capability
And yes that is correct it has the e6500 core using PowerPC.
On Tue, Oct 22, 2019 at 11:24 AM Wayne Li wrote:
> If I run "lsmod | grep kvm" nothing shows up but if I just do a "find .
> -name "kvm"" I get the following:
>
> ./usr/src/kernel/Documentation/virtual/kvm
> ./usr/src/kernel/arch/arm/kvm
> ./usr/src/kernel/arch/arm64/kvm
> ./usr/src/kernel/arch/mips/kvm
> ./usr/src/kernel/arch/powerpc/kvm
> ./usr/src/kernel/arch/s390/kvm
> ./usr/src/kernel/arch/tile/kvm
> ./usr/src/kernel/arch/x86/kvm
> ./usr/src/kernel/drivers/s390/kvm
> ./usr/src/kernel/include/config/kvm
> ./usr/src/kernel/include/config/have/kvm
> ./usr/src/kernel/include/kvm
> ./usr/src/kernel/virt/kvm
> ./dev/kvm
> ./sys/devices/virtual/misc/kvm
> ./sys/class/misc/kvm
> ./sys/kernel/debug/kvm
> ./sys/module/kvm
>
> I guess this shows my OS does have KVM on it? I added the two flags you
> mentioned when running QEMU (the -cpu and the -machine flags) but the -cpu
> flag doesn't seem like it's doing anything as even when I put a clearly
> wrong argument after the flag no error related to the cpu is thrown. Also
> it says ppce500 is not a machine type and that the supported machines are:
>
> bamboo bamboo
> boeing-machine Boeing Machine
> none empty machine
> ref405ep ref405ep
> taihutaihu
> virtex-ml507 Xilinx Virtex ML507 reference design
>
> The one being used right now is boeing-machine which is clearly specific
> to the project I am working on. I'm not exactly sure what boeing-machine
> refers to but I'll ask the person who wrote the code that specified that
> machine,
>
> On Tue, Oct 22, 2019 at 2:04 AM Thomas Huth wrote:
>
>> On 21/10/2019 23.06, Wayne Li wrote:
>> > Dear Qemu list members,
>> >
>> > I'm attempting to enable KVM in a Qemu-based project that is running on
>> > a T4240RDB board. After compiling my code with the -enable-kvm option I
>> > ran the qemu executable with the -enable-kvm option. The application
>> > exited with the following error message: "kvm error: missing PVR setting
>> > capability." What are some possibilities causing this error?
>>
>> That's an e6500 bas PPC board, isn't it? ... I guess nobody has been
>> running KVM on such a system in a while...
>>
>> What do you get when running "lsmod | grep kvm" ? How did you run QEMU?
>> I think you have to make sure to run with the right CPU model ("-cpu
>> e6500") and machine (likely "-M ppce500" ?).
>>
>> Thomas
>>
>>
QEMU VM hangs on ioctl call when running with KVM enabled and nothing else happens.
Dear QEMU list members, We developed a virtual machine using the QEMU code. This virtual machine emulates a certain custom-made computer that runs on a certain military platform. All I can tell you about this virtual machine is that it emulates a computer that has an e5500 processor. Currently I am running this virtual machine on a T4240-RDB which has a PowerPC e6500 processor (if anyone remembers me posting about this same project earlier, we fixed the TCG problem thanks to you guys!). Anyway, right now I'm trying to get this virtual machine working with KVM enabled. It should work given that the virtual machine is emulating an e5500 processor and it's running on a board with an e6500 processor. We're also using a kernel I built using Yocto and I'm pretty sure KVM is all good and working in this kernel (this was a whole story in it of itself, but if you're curious you can see my post history concerning getting KVM in the kernel). But for some reason the VM hangs on an ioctl call when KVM is enabled and nothing else happens. Now I don't think this hanging is necessarily the problem. I think what might be the case is that after the VM makes the ioctl call, the VM should start running the operating system. But this doesn't seem to be happening; when I look at "info registers" I see that the NIP has the address of the start instruction of the operating system but nothing changes and the NIP doesn't progress from that point. Let me give some further detail on the subject. With some investigation using print statements/breakpoints I see that the VM enters into the following function call in the code (I included the call stack): qemu_kvm_cpu_thread_fn -> kvm_cpu_exec(cpu) -> kvm_vcpu_ioctl(cpu, KVM_RUN, 0) -> ioctl(cpu->kvm_fd, KVM_RUN, arg) So the VM enters into a kernel level ioctl call of type KVM_RUN. And after putting some print statements into the Yocto kernel itself I see that the VM enters into a function in the kernel code called kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu) and then enters a function calling assembly code like so: ret = __kvmppc_vcpu_run(kvm_run, vcpu). At this point since __kvmppc_vcpu_run() is a function calling assembly code in the kernel, I have not been able to follow this call any further. But looking over the assembly code of this function I see some swapping of vCPU and host registers as well as a return-from-interrupt instruction at the end. See assembly code taken from bookehv_interrupts.S: https://gist.github.com/WayneZhenLi/137a748dad3eebc9be6e9b7b1a49268e At this point I have two theories on what is happening: 1. __kvmppc_vcpu_run is hitting the return from interrupt and the NIP of the VM is set to the start address of the operating system. But for some KVM-related reason, the operating system isn't able to progress and we see the NIP stuck at the starting address. 2. The return from interrupt is either not being reached or is sending me to some unknown address and thus the operating system is never run. Perhaps I see the NIP in "info registers" pointed at the starting address because of some startup thing QEMU does. But maybe this doesn't reflect the actual position of the VM? One more symptom of something not being quite right is this all describes the second KVM_RUN ioctl call being run. Before this ioctl call, there is actually another KVM_RUN ioctl call that runs and completes, but fails with an error saying "kvm_run failed Interrupted system call". I'm not sure how relevant that is but I just wanted to mention it in case it's important. Anyway, I'm really not sure what the problem is. This is everything I know at the moment but I really don't a have a good idea on why the operating system code isn't being run. Please let me know your thoughts. -Thanks!, Wayne Li
[no subject]
Dear QEMU list members, This will kind of be a repost but I'd like to post my question again because I've gained some more knowledge that makes me feel that my question would be easier to answer. So we developed a custom-made QEMU VM that emulates a custom machine that has an e5500 processor. I'm running this VM on a T4240-RDB board which has an e6500 processor and I'm trying to get the VM running with KVM enabled. The problem I'm having is the program counter refuses to increment at all. It just stays at the address 0xFFFC. On a run without KVM enabled, the VM will also start executing at this same address but the program counter beings to increment immediately. I know this is a custom QEMU VM and maybe some of the startup stuff we do could be causing problems, but what could possibly stop the program counter from incrementing altogether? Also, I do have another side question. When running with KVM enabled, I see the kernel-level ioctl call KVM_RUN running and then returning over and over again (by the way before the VM kinda grinds to a halt I only see QEMU make the KVM_RUN call twice, but the kernel-level ioctl function is being called over and over again for some reason). And each time the KVM_RUN call returns, the return-from-interrupt takes the VM to the address 0xFFFC. What is the KVM_RUN ioctl call used for? Why is it being called over and over again? Maybe if I understood this better I'd be able to figure out what's stopping my program counter from incrementing. -Thanks, Wayne Li
Re:
Thanks for the KVM_RUN explanation, that makes a lot of sense. Though I'm pretty sure I'm getting the live program counter value because I use the "info registers" command in QEMU monitor and that calls kvm_cpu_synchronize_state(). And also to be more sure, I added a few assembly instructions into the kernel code that stored a value that constantly incremented and the program counter into two general purpose registers. I was able to see both of these in QEMU monitor so the program counter must actually be stuck at 0xfffc. On Thu, Feb 20, 2020 at 3:57 AM Peter Maydell wrote: > On Thu, 20 Feb 2020 at 05:41, Wayne Li wrote: > > Also, I do have another side question. When running with KVM enabled, I > >see the kernel-level ioctl call KVM_RUN running and then returning over > >and over again (by the way before the VM kinda grinds to a halt I only see > >QEMU make the KVM_RUN call twice, but the kernel-level ioctl function > >is being called over and over again for some reason). And each time the > >KVM_RUN call returns, the return-from-interrupt takes the VM to the > >address 0xFFFC. What is the KVM_RUN ioctl call used for? Why > >is it being called over and over again? Maybe if I understood this better > >I'd be able to figure out what's stopping my program counter from > incrementing. > > KVM_RUN is the ioctl which QEMU uses to tell the kernel "hey, please > start running the guest". The kernel will not return control to QEMU > (ie the syscall will not return) until something happens that needs > QEMU's intervention, of which the main one is "guest made a device > access that QEMU must handle". (You can see this run loop in > accel/kvm/kvm-all.c:kvm_cpu_exec()). So in normal operation, > QEMU will do a bunch of setup, and then call KVM_RUN, which > will cause the guest to run, probably for quite a long time. The > ioctl will return when the guest does some IO a QEMU-provided > device, and QEMU will then do that device emulation, set up the > kvm_run struct fields to hold the results of the device access, > and call KVM_RUN again. The cycle continues like this until the > VM is shut down. If the guest goes into an infinite loop, you > should expect that KVM_RUN will never return, as there's never > any need for the kernel to ask QEMU to do anything. > > Also important to note: before we call KVM_RUN we push > the CPU register state up to the kernel (using various arch-specific > ioctls), and after that the 'live copy' of the data is in the kernel, > and values in the CPU state struct in QEMU are stale. We only > get the up to date data out of the kernel when we need it, by > calling kvm_cpu_synchronize_state(). So if your 0xfffc value > comes from the CPU state struct and you're reading it at a > point before the state has been synchronized back from the > kernel it's not going to be the actual PC value. > > The KVM kernel API is comparatively well documented at > https://www.kernel.org/doc/html/latest/virt/kvm/api.html > though the section on KVM_RUN is pretty weak. > > thanks > -- PMM >
QEMU VM crashes when enabling KVM
Dear QEMU list members,
So we developed a virtual machine that that runs on QEMU. The virtual
machine emulates a certain piece of equipment running on a PowerPC 7457
processor. And we are running the virtual machine on a T4240-RDB which as
a PowerPC e6500 processor. I can't give any more details than that as this
project has military applications.
The problem I'm having right now is when I use the -enable-kvm option when
starting the virtual machine, the virtual machine crashes like so:
kvm error: missing PVR setting capability
kvm_init_vcpu failed: Function not implemented
common_qemu_exit() has been called
Now I am fairly sure KVM is actually enabled on the system. Finding that
out was another story that spanned a couple of months. But long story
short, lsmod doesn't show that the KVM kernel module is running. But
that's because KVM is built-in and it can't actually be built as a loadable
kernel module in this particular system.
So I'm not really sure what could be the problem. Though I was thinking if
I understood the error better that might help? Following the code I see
that the "Missing PVR setting capability." is called when a variable called
"cap_segstate" is 0:
if (!cap_segstate) {
fprintf(stderr, "kvm error: missing PVR setting capability\n");
return -ENOSYS;
}
And the cap_segstate variable is set by the following function:
cap_segstate = kvm_check_extension(s, KVM_CAP_PPC_SEGSTATE);
>From there I'm pretty lost; I simply don't understand what any of these
terms mean. Do any of you guys know what PVR setting capability,
cap_segstate, or KVM_CAP_PPC_SEGSTATE mean? Do I have to set up any kind
of communication between my virtual machine and KVM? Any of you guys know
what's going on here? I'm just pretty lost right now haha.
-Thanks, Wayne Li
Re: QEMU VM crashes when enabling KVM
We wrote a project that is created on top of the QEMU source code; it calls
functions from the QEMU code. I run the executable created by compiling
that project/QEMU code. Anyway, looking at the following documentation:
https://www.kernel.org/doc/Documentation/powerpc/cpu_families.txt
It looks like the PowerPC 7457 is Book3S and the PowerPC e6500 is BookE.
Is that why you think I require a Book3S KVM? Exactly why do you feel this
way? Also would that mean my team would need to go and buy a board with a
Book3S processor?
-Thanks!, Wayne Li
>From my understanding
On Wed, Dec 11, 2019 at 7:16 PM Paolo Bonzini wrote:
> On 11/12/19 22:23, Wayne Li wrote:
> >
> > Now I am fairly sure KVM is actually enabled on the system. Finding
> > that out was another story that spanned a couple of months. But long
> > story short, lsmod doesn't show that the KVM kernel module is running.
> > But that's because KVM is built-in and it can't actually be built as a
> > loadable kernel module in this particular system.
> >
> > So I'm not really sure what could be the problem. Though I was thinking
> > if I understood the error better that might help? Following the code I
> > see that the "Missing PVR setting capability." is called when a variable
> > called "cap_segstate" is 0:
> >
> > if (!cap_segstate) {
> > fprintf(stderr, "kvm error: missing PVR setting
> capability\n");
> > return -ENOSYS;
> > }
> >
> > And the cap_segstate variable is set by the following function:
> >
> > cap_segstate = kvm_check_extension(s, KVM_CAP_PPC_SEGSTATE);
>
> You are not saying how you are running QEMU. I think you are using a
> CPU model that requires a Book3S KVM.
>
> Paolo
>
>
Re: QEMU VM crashes when enabling KVM
Dear David Gibson,
I know you are under no obligation to respond, but if it's possible for you
to find the time to respond to my question, I would be extremely grateful.
My team at Boeing has been stuck trying to get KVM working for our project
for the last few months. A good explanation of why this isn't possible
would be absolutely critical.
-Thanks, Wayne Li
On Thu, Dec 12, 2019 at 1:17 AM Paolo Bonzini wrote:
> On 12/12/19 02:59, Wayne Li wrote:
> > We wrote a project that is created on top of the QEMU source code; it
> > calls functions from the QEMU code. I run the executable created by
> > compiling that project/QEMU code. Anyway, looking at the following
> > documentation:
> >
> > https://www.kernel.org/doc/Documentation/powerpc/cpu_families.txt
> >
> > It looks like the PowerPC 7457 is Book3S and the PowerPC e6500 is
> > BookE. Is that why you think I require a Book3S KVM? Exactly why do
> > you feel this way? Also would that mean my team would need to go and
> > buy a board with a Book3S processor?
>
> CCing the PPC maintainer. There are aspects of BookE and Book3S that
> are different and not really interchangeable in the privileged interface.
>
> Paolo
>
> > -Thanks!, Wayne Li
> >
> > From my understanding
> >
> > On Wed, Dec 11, 2019 at 7:16 PM Paolo Bonzini > <mailto:pbonz...@redhat.com>> wrote:
> >
> > On 11/12/19 22:23, Wayne Li wrote:
> > >
> > > Now I am fairly sure KVM is actually enabled on the system.
> Finding
> > > that out was another story that spanned a couple of months. But
> long
> > > story short, lsmod doesn't show that the KVM kernel module is
> > running.
> > > But that's because KVM is built-in and it can't actually be built
> as a
> > > loadable kernel module in this particular system.
> > >
> > > So I'm not really sure what could be the problem. Though I was
> > thinking
> > > if I understood the error better that might help? Following the
> > code I
> > > see that the "Missing PVR setting capability." is called when a
> > variable
> > > called "cap_segstate" is 0:
> > >
> > > if (!cap_segstate) {
> > > fprintf(stderr, "kvm error: missing PVR setting
> > capability\n");
> > > return -ENOSYS;
> > > }
> > >
> > > And the cap_segstate variable is set by the following function:
> > >
> > > cap_segstate = kvm_check_extension(s, KVM_CAP_PPC_SEGSTATE);
> >
> > You are not saying how you are running QEMU. I think you are using a
> > CPU model that requires a Book3S KVM.
> >
> > Paolo
> >
>
>
Re: QEMU VM crashes when enabling KVM
Thanks David and Zalton for the awesome explanations. They're very helpful to us! -Thanks, Wayne Li On Thu, Dec 12, 2019 at 9:49 PM David Gibson wrote: > On Thu, Dec 12, 2019 at 10:40:44AM -0600, Wayne Li wrote: > > Dear David Gibson, > > > > I know you are under no obligation to respond, but if it's possible for > you > > to find the time to respond to my question, I would be extremely > grateful. > > My team at Boeing has been stuck trying to get KVM working for our > project > > for the last few months. A good explanation of why this isn't possible > > would be absolutely critical. > > As you can see from that diagram, the history ppc CPUs is quite a bit > more diverse than x86. Although they're all very similar from the > point of view of userspace code, they're quite different for > privileged kernel code: they have different MMUs, different privileged > registers amongst other things. > > Because of this there are several different KVM implementations. > > 1) KVM HV > > This one uses the virtualization facilities of BookS CPUs (present > since POWER4 / 970, but only well supported from POWER7 onwards). > Those don't allow much to virtualize the guest cpu model, so it > assumes the guest cpu is the same as the host. > > So, both your guest and host CPUs rule this one out. > > 2) Book3E KVM > > Uses the virtualization features of recent enough Freescale Book E > CPUs. I don't know a lot about this or its limitations. The e6500 > might well have these features, but I'm pretty sure it can only > emulate BookE cpus for the guest. > > So, your guest rules this one out. > > 3) KVM PR > > This one operates by running the entire guest in user mode, and > emulating all privileged instructions. It's slow (relative to > hardware assisted KVM models), but it's flexible. > > In theory, this one can do what you want, but there are a bunch of > caveats: > > * Emulating all the privileged instructions for a whole bunch of cpu > variants is a huge task, and KVM PR is now barely maintained. There > are lots of gaps in coverage. > > * I'm not sure if it was ever really implemented for BookE hosts. > > * Although there aren't many, there are a few differences between > userland instructions between cpu variants, mostly because of new > additions. I think 7457 is an old enough design that this probably > won't cause you troube, but I'm not certain. > > > > > > > -Thanks, Wayne Li > > > > On Thu, Dec 12, 2019 at 1:17 AM Paolo Bonzini > wrote: > > > > > On 12/12/19 02:59, Wayne Li wrote: > > > > We wrote a project that is created on top of the QEMU source code; it > > > > calls functions from the QEMU code. I run the executable created by > > > > compiling that project/QEMU code. Anyway, looking at the following > 0> > > documentation: > > > > > > > > https://www.kernel.org/doc/Documentation/powerpc/cpu_families.txt > > > > > > > > It looks like the PowerPC 7457 is Book3S and the PowerPC e6500 is > > > > BookE. Is that why you think I require a Book3S KVM? Exactly why do > > > > you feel this way? Also would that mean my team would need to go and > > > > buy a board with a Book3S processor? > > > > > > CCing the PPC maintainer. There are aspects of BookE and Book3S that > > > are different and not really interchangeable in the privileged > interface. > > > > > > Paolo > > > > > > > -Thanks!, Wayne Li > > > > > > > > From my understanding > > > > > > > > On Wed, Dec 11, 2019 at 7:16 PM Paolo Bonzini > > > <mailto:pbonz...@redhat.com>> wrote: > > > > > > > > On 11/12/19 22:23, Wayne Li wrote: > > > > > > > > > > Now I am fairly sure KVM is actually enabled on the system. > > > Finding > > > > > that out was another story that spanned a couple of months. > But > > > long > > > > > story short, lsmod doesn't show that the KVM kernel module is > > > > running. > > > > > But that's because KVM is built-in and it can't actually be > built > > > as a > > > > > loadable kernel module in this particular system. > > > > > > > > > > So I'm not really sure what could be the problem. Though I was > > > > thinking > > > > > if I under
Re: Need help understanding assertion fail.
I see. So you're saying that it might be possible that my guest could be generating TCG ops that can't be translated into PPC instructions because the displacement value is to big. While the same TCG ops can be translated into x86 instructions because x86 allows for a bigger displacement value. But on the other hand it could be some other problem causing me to have a large displacement value. In that case, I think it'd be super helpful if I print out this displacement value in the TCG ops when running on PPC versus x86 because they should be the same right? What option in QEMU -d allows me to see generated TCG ops? Doing a -d --help shows the following options: out_asmshow generated host assembly code for each compiled TB in_asm show target assembly code for each compiled TB op show micro ops for each compiled TB op_opt show micro ops (x86 only: before eflags optimization) and after liveness analysis intshow interrupts/exceptions in short format exec show trace before each executed TB (lots of logs) cpushow CPU state before block translation mmulog MMU-related activities pcall x86 only: show protected mode far calls/returns/exceptions cpu_reset show CPU state before CPU resets ioport show all i/o ports accesses unimp log unimplemented functionality guest_errors log when the guest OS does something invalid (eg accessing a non-existent register) There doesn't seem to be any option to print out the TCG ops specifically? Maybe I'll have to go into the code to add print statements that print out the TCG ops? -Thanks!, Wayne Li On Mon, Feb 3, 2020 at 10:56 AM Peter Maydell wrote: > On Mon, 3 Feb 2020 at 16:39, Wayne Li wrote: > > Anyway that's the background. The specific problem I'm having right now > is I get the following assertion error during some of the setup stuff our > OS does post boot-up (the OS is also custom-made): > > > > qemu_programs/qemu/tcg/ppc/tcg-target.inc.c:224: reloc_pc14_val: > Assertion `disp == (int16_t) disp' failed. > > > > Looking at the QEMU code, "disp" is the difference between two pointers > named "target" and "pc". I'm not sure exactly what either of those names > mean. And it looks like since the assertion is checking if casting "disp" > as a short changes the value, it's checking if the "disp" value is too > big? I'm just not very sure what this assertion means. > > This assertion is checking that we're not trying to fit too > large a value into the host PPC branch instruction we just emitted. > That is, tcg_out_bc() emits a PPC conditional branch instruction, > which has a 14 bit field for the offset (it's a relative branch), > and we know the bottom 2 bits of the target will be 0 (PPC insns > being 4-aligned), so the distance between the current host PC > and the target of the branch must fit in a signed 16-bit field. > > "disp" here stands for "displacement". > > The PPC TCG backend only uses this for the TCG 'brcond' and > 'brcond2' TCG intermediate-representation ops. It seems likely > that the code for your target is generating TCG ops which have > too large a gap between a brcond/brcond2 and the destination label. > You could try using the various QEMU -d options to print out the > guest instructions and the generated TCG ops to pin down what > part of your target is trying to generate branches over too > much code like this. > > > Anyway, the thing is this problem has to be somehow related to > > the transfer of the code from a little-endian platform to a > > big-endian platform as our project works without any problem on > > little-endian platforms. > > In this case it isn't necessarily directly an endianness issue. > The x86 instruction set provides conditional branch instructions > which allow a 32-bit displacement value, so you're basically never > going to overflow a conditional-branch there. PPC, being RISC, > has more limited branch insns. You might also run into this > if you tried to use aarch64 (64-bit) arm hosts, which are > little-endian but have a 19-bit branch displacement limit, > depending on just how big you've managed to make your jumps. > On the other hand, a 16-bit displacement is a jump over > 64K of generated code, which is huge for a single TCG > generated translation block, so it could well be that you > have an endianness bug in your TCG frontend which is causing > you to generate an enormous TB by accident. > > thanks > -- PMM >
Re: Missing PVR setting capability
So it's been a little while and I've been trying some different approaches. I think the problem I am having is because I don't have the required kernel modules loaded. When I run lsmod I only see the following two modules loaded: Module Size Used by nfsd 100940 11 exportfs6723 1 nfsd The archlinux website says the following modules need to be running: kvm_intel 245760 0 kvmgt 28672 0 mdev 20480 2 kvmgt,vfio_mdev vfio 32768 3 kvmgt,vfio_mdev,vfio_iommu_type1 kvm 737280 2 kvmgt,kvm_intel irqbypass 16384 1 kvm Granted that I am running on a powerpc processor not an intel processor, the modules that I myself to need to load will be a little different from that. But I can't find those modules to load on my device. For example, I can't find a kvm.ko file on the device despite the fact that I was able to find the kvm directories I mentioned earlier. Did I have to compile those modules myself? In the kvm module directory there is C code and a makefile, but just running make doesn't work. Note that I'm using a Yocto Linux system that I myself didn't build. My coworker built the Linux system on SD card and was in the process of trying to figure out if kvm was actually enabled on the system or not before he left the company. I'm learning about the system as I go. On Tue, Oct 22, 2019 at 1:46 PM Thomas Huth wrote: > On 22/10/2019 18.24, Wayne Li wrote: > > If I run "lsmod | grep kvm" nothing shows up but if I just do a "find . > > -name "kvm"" I get the following: > [...] > > ./sys/devices/virtual/misc/kvm > > ./sys/class/misc/kvm > > ./sys/kernel/debug/kvm > > ./sys/module/kvm > > > > I guess this shows my OS does have KVM on it? > > Alright, I guess that means that KVM compiled into the kernel ... should > be fine, I think. > > > I added the two flags you > > mentioned when running QEMU (the -cpu and the -machine flags) but the > > -cpu flag doesn't seem like it's doing anything as even when I put a > > clearly wrong argument after the flag no error related to the cpu is > > thrown. Also it says ppce500 is not a machine type and that the > > supported machines are: > > > > bamboo bamboo > > boeing-machine Boeing Machine > > none empty machine > > ref405ep ref405ep > > taihutaihu > > virtex-ml507 Xilinx Virtex ML507 reference design > > Oh, are you running qemu-system-ppc instead of qemu-system-ppc64? I > thought these e*500 CPUs are 64-bit? Is your host kernel 64-bit or 32-bit? > > Anyway, if you're using a modified version of QEMU, you should > definitely ask the people who did the modifications there. > > Thomas > >
Need help understanding assertion fail.
Dear QEMU list members, So we developed a virtual machine using the QEMU code. This virtual machine emulates a certain custom-made computer that runs on a certain military platform. All I can tell you about this virtual machine is that emulates a computer that has a PowerPC 7457 processor. Anyway, we developed this virtual machine using QEMU on little endian machines (i.e. like your typical desktop running Windows). What I'm working on right now is getting this virtual machine to work on a T4240-RDB which has a PowerPC e6500 processor. The biggest roadblock I face when trying to get this to work relates to the fact that the T4240-RDB is a big-endian machine and transferring our code from a little-endian machine to a big-endian machine created a lot of problems due to a lot of bad practices the team made when they developed the virtual machine. Anyway that's the background. The specific problem I'm having right now is I get the following assertion error during some of the setup stuff our OS does post boot-up (the OS is also custom-made): qemu_programs/qemu/tcg/ppc/tcg-target.inc.c:224: reloc_pc14_val: Assertion `disp == (int16_t) disp' failed. Looking at the QEMU code, "disp" is the difference between two pointers named "target" and "pc". I'm not sure exactly what either of those names mean. And it looks like since the assertion is checking if casting "disp" as a short changes the value, it's checking if the "disp" value is too big? I'm just not very sure what this assertion means. Anyway, the thing is this problem has to be somehow related to the transfer of the code from a little-endian platform to a big-endian platform as our project works without any problem on little-endian platforms. But I think it would be really helpful if I knew more about this assertion. What exactly is trying to check for here and why? Do you see how it could relate to endianism issues in any way? -Thanks!, Wayne Li
Problem with virtual to physical memory translation when KVM is enabled.
Dear KVM list members, We developed a virtual machine using the QEMU code. This virtual machine emulates a certain custom-made computer that runs on a certain military platform. All I can tell you about this virtual machine is that it emulates a computer that has an e5500 processor. Currently I am running this virtual machine on a T4240-RDB which has a PowerPC e6500 processor. Anyway, right now I’m trying to get this virtual machine working with KVM enabled. But the problem I’m having is the VM doesn’t do anything after the KVM_RUN ioctl call is made (NIP doesn’t progress and no registers change). What seems to be the problem is the VM doesn’t run the instruction that’s supposed to be retrieved from the virtual address 0x_FFFC. When KVM isn’t enabled and the VM is running using TCG (tiny code generator), a branch instruction to 0x_F700 is retrieved from the virtual address 0x_FFFC and the VM kicks off running from there. So what could be causing this problem? I’m guessing it has something to do with the translation lookaside buffers (TLBs)? But the translation between virtual and physical memory clearly works when KVM isn’t enabled. So what could cause this to stop working when KVM is enabled? Or maybe I’m not understanding something right and missing what the problem actually is? Let me know your thoughts. -Thanks, Wayne Li
QEMU RAM allocation function fails
Dear QEMU list members,
We developed a virtual machine that runs on QEMU. This virtual
machine is pretty much an emulated P4080 processor with some
peripherals attached. Initializing one of these peripherals, i.e. the
RAM, seems to be having problems. I use the function
"memory_region_init_ram" to initialize the RAM and farther down the
call stack I see that the "qemu_ram_alloc" function returns an address
of 0 proving the RAM allocation wasn't successful. Here is the block
of code in question copied from the file memory.c:
void memory_region_init_ram_shared_nomigrate(MemoryRegion *mr,
Object *owner,
const char *name,
uint64_t size,
bool share,
Error **errp)
{
memory_region_init(mr, owner, name, size);
mr->ram = true;
mr->terminates = true;
mr->destructor = memory_region_destructor_ram;
mr->ram_block = qemu_ram_alloc(size, share, mr, errp);
mr->dirty_log_mask = tcg_enabled() ? (1 << DIRTY_MEMORY_CODE) : 0;
}
Tracing farther into the "qemu_ram_alloc" function reveals that the
function fails because inside the "qemu_ram_alloc_internal" function
in file exec.c, the function "ram_block_add" fails. Interestingly, a
local_err object is populated here and the msg field in this object is
populated with the String "cannot set up guest memory 'ram0': Invalid
argument". Here is the block of code in question copied from the file
exec.c:
RAMBlock *qemu_ram_alloc_internal(ram_addr_t size, ram_addr_t max_size,
void (*resized)(const char*,
uint64_t length,
void *host),
void *host, bool resizeable, bool share,
MemoryRegion *mr, Error **errp)
{
RAMBlock *new_block;
Error *local_err = NULL;
size = HOST_PAGE_ALIGN(size);
max_size = HOST_PAGE_ALIGN(max_size);
new_block = g_malloc0(sizeof(*new_block));
new_block->mr = mr;
new_block->resized = resized;
new_block->used_length = size;
new_block->max_length = max_size;
assert(max_size >= size);
new_block->fd = -1;
new_block->page_size = getpagesize();
new_block->host = host;
if (host) {
new_block->flags |= RAM_PREALLOC;
}
if (resizeable) {
new_block->flags |= RAM_RESIZEABLE;
}
ram_block_add(new_block, &local_err, share);
if (local_err) {
g_free(new_block);
error_propagate(errp, local_err);
return NULL;
}
return new_block;
}
Anyway, our VM runs fine until it tries to access the RAM region so
this is a pretty critical problem for us to solve. Does anyone know
much about these QEMU functions? What could be causing these RAM
initialzation functions to fail in this way?
-Thanks, Wayne Li
Re: QEMU RAM allocation function fails
The RAM region was just too big. I made it smaller and the VM didn't
crash and moved past that point.
On Thu, Nov 5, 2020 at 1:58 PM Dr. David Alan Gilbert
wrote:
>
> * Wayne Li (waynli...@gmail.com) wrote:
> > Dear QEMU list members,
> >
> > We developed a virtual machine that runs on QEMU. This virtual
> > machine is pretty much an emulated P4080 processor with some
> > peripherals attached. Initializing one of these peripherals, i.e. the
> > RAM, seems to be having problems. I use the function
> > "memory_region_init_ram" to initialize the RAM and farther down the
> > call stack I see that the "qemu_ram_alloc" function returns an address
> > of 0 proving the RAM allocation wasn't successful. Here is the block
> > of code in question copied from the file memory.c:
> >
> > void memory_region_init_ram_shared_nomigrate(MemoryRegion *mr,
> > Object *owner,
> > const char *name,
> > uint64_t size,
> > bool share,
> > Error **errp)
> > {
> > memory_region_init(mr, owner, name, size);
> > mr->ram = true;
> > mr->terminates = true;
> > mr->destructor = memory_region_destructor_ram;
> > mr->ram_block = qemu_ram_alloc(size, share, mr, errp);
> > mr->dirty_log_mask = tcg_enabled() ? (1 << DIRTY_MEMORY_CODE) : 0;
> > }
> >
> > Tracing farther into the "qemu_ram_alloc" function reveals that the
> > function fails because inside the "qemu_ram_alloc_internal" function
> > in file exec.c, the function "ram_block_add" fails. Interestingly, a
> > local_err object is populated here and the msg field in this object is
> > populated with the String "cannot set up guest memory 'ram0': Invalid
> > argument". Here is the block of code in question copied from the file
> > exec.c:
>
> I'm surprised something didn't print that message out for you - most
> callers pass something like &error_fatal at the end and it should print
> it I think.
>
> >
> > RAMBlock *qemu_ram_alloc_internal(ram_addr_t size, ram_addr_t max_size,
> > void (*resized)(const char*,
> > uint64_t length,
> > void *host),
> > void *host, bool resizeable, bool share,
> > MemoryRegion *mr, Error **errp)
> > {
> > RAMBlock *new_block;
> > Error *local_err = NULL;
> >
> > size = HOST_PAGE_ALIGN(size);
> > max_size = HOST_PAGE_ALIGN(max_size);
> > new_block = g_malloc0(sizeof(*new_block));
> > new_block->mr = mr;
> > new_block->resized = resized;
> > new_block->used_length = size;
> > new_block->max_length = max_size;
> > assert(max_size >= size);
> > new_block->fd = -1;
> > new_block->page_size = getpagesize();
> > new_block->host = host;
> > if (host) {
> > new_block->flags |= RAM_PREALLOC;
> > }
> > if (resizeable) {
> > new_block->flags |= RAM_RESIZEABLE;
> > }
> > ram_block_add(new_block, &local_err, share);
> > if (local_err) {
> > g_free(new_block);
> > error_propagate(errp, local_err);
> > return NULL;
> > }
> > return new_block;
> > }
> >
> > Anyway, our VM runs fine until it tries to access the RAM region so
> > this is a pretty critical problem for us to solve. Does anyone know
> > much about these QEMU functions? What could be causing these RAM
> > initialzation functions to fail in this way?
>
> You're going the right way - keep following it; that 'cannot set up
> guest memory' string is only in one place; softmmu/physmem.c - so
> the phys_mem_alloc must have failed. That suggests either your
> max_length or your align requirements are wrong; but keep following
> it along.
>
> Dave
>
> > -Thanks, Wayne Li
> >
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>
