Re: QEMU Library support

s. Regards, Pratik On Mon, Aug 10, 2020 at 3:18 PM Alex Bennée wrote: > > Pratik Parvati writes: > > > Hi team, > > > > Lately, I have been working on QEMU modeling and interfacing it into the > > existing platform. What actually I wanted to check is; whether

Re: QEMU Library support

Just to hide the core QEMU implementation from the device code. QEMU core source code remains the same for all device; So, was thinking a way of hiding it from the rest of the device code. Regards, Pratik On Mon, Aug 10, 2020 at 3:50 PM Alex Bennée wrote: > > Pratik Parvati

Re: QEMU Library support

and include files to add support for the new device. If QEMU doesn't provide a library, Is there a flexibly that I can tweak something inside the QEMU to generate it? Regards, Pratik On Mon, Aug 10, 2020 at 3:18 PM Alex Bennée wrote: > > Pratik Parvati writes: > > > Hi team, > > &g

QEMU Library support

Hi team, Lately, I have been working on QEMU modeling and interfacing it into the existing platform. What actually I wanted to check is; whether QEMU supports library that gives developers a clean interface to develop and integrate peripheral model in to QEMU. I know of the Greensocs SystemC

Re: sysbus_create_simple Vs qdev_create

h method to use while creating an object? Thanks & Regards, Pratik On Tue, Jul 14, 2020 at 9:39 PM Pratik Parvati wrote: > Hi Support team, > > Can someone please guide me to understand the difference between > *sysbus_create_simple > *and *qdev_create*?. > > I understand

sysbus_create_simple Vs qdev_create

Hi Support team, Can someone please guide me to understand the difference between *sysbus_create_simple *and *qdev_create*?. I understand that these two methods are used to create a new device. But, when to use these functions is not clear to me. Regards, Pratik

Re: sysbus_create_simple Vs qdev_create

> Philippe Mathieu-Daudé writes: > > > Hi Pratik, > > > > On 7/14/20 6:17 PM, Pratik Parvati wrote: > >> Here is a brief context that might help you. > >> I am referring hw/arm/versatilepb.c > >> > >> The ARM PrimeCell UART (PL011

instance_init() and the realize() functions

Hi team, Could someone please guild me to understand the difference between *instance_init()* and the* realize()* functions? The *class_init() *function is straight forward (it is similar to the constructor in C++ OOP); But I am, finding hard to quote the difference between *instance_init()* and

VMState in QEMU

Hi team, Can someone please explain to me briefly the significance of VMState in Migration. I understand that this reduces the lot of duplication of code across all the devices in QEMU with the common put and get implementation somewhere in the code. Does this have any other significance? Is it

Virtio-GPU Xres and Yres seettings

Hi Team, I am working on a Virtio-GPU device (backend) for one of our customer projects - we are using the Virtio-GPU driver (frontend) to drive our device. Our device code has been written using Qemu virtio-gpu device code as a reference. Our device is setting the resolution to 1024x768 as a

Re: Virtio-GPU Xres and Yres seettings

:41, Gerd Hoffmann wrote: > On Mon, Dec 20, 2021 at 10:44:06PM +0530, Pratik Parvati wrote: > > > EDID is optional, so you can try disable the EDID feature bit and see > > > what happens. > > > > Thanks Gerd, after disabling the EDID, I was able to get the require

Re: Virtio-GPU Xres and Yres seettings

> > Cc'ing Gerd & Marc-André. > > > > On 12/20/21 05:26, Pratik Parvati wrote: > > > Hi Team, > > > > > > I am working on a Virtio-GPU device (backend) for one of our customer > > > projects - we are using the Virtio-GPU driver (frontend) t

Re: Virtio-GPU Xres and Yres seettings

> EDID is optional, so you can try disable the EDID feature bit and see > what happens. Thanks Gerd, after disabling the EDID, I was able to get the required resolution (basically width and height) from the driver. Another strange observation - When the device receives the command