Re: [Qemu-devel] SystemC hw simulation in qemu
Can someone help me about this? I've looked at exec.c source for understand how io memory addressment go but i don't know if it's the right place to start.I see that in serial.c source there are IO and memory map function for read and write, and serial_mm_read/write functions use serial_read/write functions. The difference is the base address I see... right? Where I can find this IO address? And there is a serial_mm_init function. Is it used only all emulation except i386 or can I use it for i386 too? In other words... can I use IO memory address for serial port in 386 emulation or not?ThanksAle Ps: Be patience, I am only a poor student ;)2006/6/28, Alessandro Corradi <[EMAIL PROTECTED]>: ... The problem is that I write my simple hw, but instead use IOddress such as 0x378 I need to use memory address, so I can use it in every virtualizzation (i386, mips etc...). Where can I look for it?ThanksAle ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
On Wed, Jun 28, 2006 at 07:03:31PM -0400, Joe Lee wrote: > > > >I would be interested in a GUI that is not specific to QEMU. e.g. Xen/VT, > >Basilisk II, SheepShaver, etc. ;-) > Gwenole, can you elaborate more on your comments above. Are your > comments referring to having a GUI that can both run and manage several > virtualization product (QEMU, XEN, etc) from one central GUI interface? > If so, I had a similar thought on this BUT was not sure how possible > this was. Would like to hear more on what your thoughts are on this. > Anyone else thought and comments to this would be appreciated! Its entirely feasible if you have a management API to use which supports the different virtualization backends. That would allow the GUI to be written to a single API, and yet control multiple systems like QEMU, Xen, etc. The libvirt project aims to provide such a backend API, currently supporting Xen, and a 'mock hypervisor' backend for testing purposes, and it would be very desirable to have backends to drive QEMU & VMWare systems. While the GUI would no doubt still have some differences in the area of hardware /device configuration the bulk of it could be shared by using the generic libvirt backend. I've got an early prototype of a Python/GTK based GUI for managing VMs via libvirt: http://people.redhat.com/berrange/virt-manager/ So if anyone's interested in trying to put together a QEMU backend for libvirt the project site is http://libvirt.org/ Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu kbd emulation
> I have an ugly hack that fixes the code so there are no more key repeats,
> but I was never able to figure out what caused the key drops.
I suppose that I have same ugly hack as you:
uint32_t ps2_read_data(void *opaque)
{
[...]
if (q->count == 0) {
[...]
} else {
val = q->data[q->rptr];
if (++q->rptr == PS2_QUEUE_SIZE)
q->rptr = 0;
q->count--;
/* reading deasserts IRQ */
/*
If I comment out following line:
s->update_irq(s->update_arg, 0);
repeating keys disapear. I didn't notice negative
effects of this so far.
*/
/* reassert IRQs if data left */
s->update_irq(s->update_arg, q->count != 0);
}
return val;
}
BTW: what happens when update_irq is called?
AFAIK some interraption should be emulated but I don't know how.
Becouse ps2_queue can grow (q->count can be sth more than 1) and
becouse every time at the end of ps2_queue function update_irq is
called, I suppose that irqs are emulated by another thread.
So how they are synchronized?
--
Rafał Cygnarowski
[EMAIL PROTECTED]
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
Daniel, thanks for your info and comments below. I really like the concept and work being done with virt-manager using the libvirt API. Question: Is the virt-manager project run by Redhat or yourself? In what OS platform will virt-manager run under (Windows, Linux, OS-X) - Essentially, how cross-platform is it? -joe Daniel P. Berrange wrote: On Wed, Jun 28, 2006 at 07:03:31PM -0400, Joe Lee wrote: I would be interested in a GUI that is not specific to QEMU. e.g. Xen/VT, Basilisk II, SheepShaver, etc. ;-) Gwenole, can you elaborate more on your comments above. Are your comments referring to having a GUI that can both run and manage several virtualization product (QEMU, XEN, etc) from one central GUI interface? If so, I had a similar thought on this BUT was not sure how possible this was. Would like to hear more on what your thoughts are on this. Anyone else thought and comments to this would be appreciated! Its entirely feasible if you have a management API to use which supports the different virtualization backends. That would allow the GUI to be written to a single API, and yet control multiple systems like QEMU, Xen, etc. The libvirt project aims to provide such a backend API, currently supporting Xen, and a 'mock hypervisor' backend for testing purposes, and it would be very desirable to have backends to drive QEMU & VMWare systems. While the GUI would no doubt still have some differences in the area of hardware /device configuration the bulk of it could be shared by using the generic libvirt backend. I've got an early prototype of a Python/GTK based GUI for managing VMs via libvirt: http://people.redhat.com/berrange/virt-manager/ So if anyone's interested in trying to put together a QEMU backend for libvirt the project site is http://libvirt.org/ Regards, Dan. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
On Thu, Jun 29, 2006 at 05:05:25PM -0400, Joe Lee wrote: > Daniel, thanks for your info and comments below. I really like the > concept and work being done with virt-manager using the libvirt API. > Question: > Is the virt-manager project run by Redhat or yourself? At the moment its just me working on it - I only put up those web pages a couple of days ago so there isn't anyone else involved. The project was initiated by Red Hat, but as with all our projects we welcome involvement / contribution / feedback from any community members. > In what OS platform will virt-manager run under (Windows, Linux, OS-X) - > Essentially, how cross-platform is it? My primary target at this time is Linux. The application is written in Python with libvirt and GTK / PyGTK being primary dependancies. All the GTK stuff is portable to Windows, and libvirt should be portable too. I'm not sure what GTK OS-X support is like though. So although I'm not testing it on anything other than Linux, it should be possible to make it portable if there were demand. I honestly couldn't estimate the work to port it though, not having any experiance developing for Windows / OS-X Regards, Dan. > -joe > > Daniel P. Berrange wrote: > >On Wed, Jun 28, 2006 at 07:03:31PM -0400, Joe Lee wrote: > > > >>>I would be interested in a GUI that is not specific to QEMU. e.g. Xen/VT, > >>>Basilisk II, SheepShaver, etc. ;-) > >>> > >>Gwenole, can you elaborate more on your comments above. Are your > >>comments referring to having a GUI that can both run and manage several > >>virtualization product (QEMU, XEN, etc) from one central GUI interface? > >>If so, I had a similar thought on this BUT was not sure how possible > >>this was. Would like to hear more on what your thoughts are on this. > >>Anyone else thought and comments to this would be appreciated! > >> > > > >Its entirely feasible if you have a management API to use which supports > >the different virtualization backends. That would allow the GUI to be > >written to a single API, and yet control multiple systems like QEMU, Xen, > >etc. The libvirt project aims to provide such a backend API, currently > >supporting Xen, and a 'mock hypervisor' backend for testing purposes, and > >it would be very desirable to have backends to drive QEMU & VMWare systems. > >While the GUI would no doubt still have some differences in the area of > >hardware /device configuration the bulk of it could be shared by using > >the generic libvirt backend. I've got an early prototype of a Python/GTK > >based GUI for managing VMs via libvirt: > > > > http://people.redhat.com/berrange/virt-manager/ > > > >So if anyone's interested in trying to put together a QEMU backend for > >libvirt the project site is http://libvirt.org/ > > > >Regards, > >Dan. > > -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
