Never mind, found the answers in kvm_set_user_memory :)
On Fri, Oct 15, 2021 at 9:36 PM Ajay Garg wrote:
>
> Hello everyone.
>
> I have a x86_64 L1 guest, running on a x86_64 host, with a
> host-pci-device attached to the guest.
> The host runs with IOMMU enabled, and p
Hello everyone.
I have a x86_64 L1 guest, running on a x86_64 host, with a
host-pci-device attached to the guest.
The host runs with IOMMU enabled, and passthrough enabled.
Following are the addresses of the bar0-region of the pci-device, as
per the output of lspci -v :
* On host (hpa) =>
Is "integratorcp" the same board that rumprun is being built for
(https://github.com/rumpkernel/rumprun/tree/master/platform/hw/arch/arm/integrator)?
On Thu, Apr 12, 2018 at 9:56 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:
> Actually just realised that qemu does support
n ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
##
On Wed, Apr 11, 2018 at 12:49 PM, Ajay Garg <ajaygargn...@gmail.com> wrote:
&
t,
on what needs to be done in order to have something run on a "virt"
machine in qemu-context.
Thanks and Regards,
Ajay
On Tue, Apr 10, 2018 at 3:49 PM, Ajay Garg <ajaygargn...@gmail.com> wrote:
> Thanks Peter .. my sincere gratitude.
> You pin-pointed the real issue ..
&
Thanks Peter .. my sincere gratitude.
You pin-pointed the real issue ..
On Tue, Apr 10, 2018 at 2:50 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 10 April 2018 at 09:16, Ajay Garg <ajaygargn...@gmail.com> wrote:
>> On Tue, Apr 10, 2018 at 1:08 PM, Pete
Hi Peter.
Thanks for the reply.
On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 10 April 2018 at 05:14, Ajay Garg <ajaygargn...@gmail.com> wrote:
>> Thanks Alex for the reply ..
>>
>>>
>>> Can you run under
uot;, format@entry=0x84ad60 "pg\201", ap=...,
ap@entry=...) at vfprintf.c:1296
#6 0xb5e2ee00 in __fprintf (stream=,
format=0x263e68 "R%02d=%08x") at fprintf.c:32
#7 0x000dc352 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
##
Thanks Alex for the reply ..
>
> Can you run under -s -S and gdb step the *guest* and see where it ends
> up. The above error is usually indicative of the guest going off into
> the weeds somewhere because the hardware isn't what it expects.
>
So, after your reply that it might be because of the
Thanks a ton Peter, that cleared things up a great deal !!!
Thanks again for the quick help !!
Thanks and Regards,
Ajay
On Mon, Apr 9, 2018 at 11:17 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 9 April 2018 at 18:41, Ajay Garg <ajaygargn...@gmail.com> wro
of the hardware.)
Sorry again for my zero knowledge on the ARM world.
On Mon, Apr 9, 2018 at 7:31 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 9 April 2018 at 14:43, Ajay Garg <ajaygargn...@gmail.com> wrote:
>> On Mon, Apr 9, 2018 at 7:08 PM, Pete
Hi Peter,
Thanks for the reply ..
On Mon, Apr 9, 2018 at 7:08 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 9 April 2018 at 14:35, Ajay Garg <ajaygargn...@gmail.com> wrote:
>> Hi All.
>>
>> Not sure if this is purely an ARM-related question, but I wil
Hi All.
Not sure if this is purely an ARM-related question, but I will be
grateful if someone could point to some literature that explains what
difference choosing a machine makes (when we don't need to have any
such flag for qemu-system-i386 or qemu-system-x86_64).
I am sorry for the noob
>
> qemu-system-x86_64 is expecting an x86 binary blob. I assume you need
> qemu-system-arm. More importantly you need to specify a -M machine type
> that matches whatever rumprun is expecting.
>
Oops, sorry my bad.
Here is the updated status :
ajay@latitude-3480:~/rumprun-arm-hw/rumprun$
Hi All.
We did the following :
a)
Cross-compile rumprun for ARM on a linux x86_64 :
ajay@latitude-3480:~/rumprun-arm-hw/rumprun$
CC=arm-linux-gnueabihf-gcc ./build-rr.sh hw
b)
Compile and bake the hello-world binary
ajay@latitude-3480:~/rumprun-arm-hw/rumprun$
arm-rumprun-netbsdelf-eabihf-gcc
15 matches
Mail list logo
