Forgot to mention, the KQEMU installer seems to be lacking a check for what
version of Windows is in use, this needs fixing too.
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
It is not mentioned that KQEMU is incompatible with Win98SE.
Suggested fix: support Win98SE. Is there a good technical reason why it
can't be supported?
Temporary workaround: clearly state on the webpage and in documentation that
KQEMU is not compatible with Win9x. (This has wasted a considerable
I am using qemu-dm 0.8.2 of xen 3.0.3, and found that use "usb_add"
command to enable some usb disks may cause the guest OS not responding,
while enable other usb disks cause no problem. I searched the archive
but didn't found a similar report. Has anyone met the same problem?
Thanks
Xiaoyang
This is relative to the 20070319 snapshot.
--- audio/ossaudio.c.orig Mon Feb 5 17:01:54 2007
+++ audio/ossaudio.cSat Mar 10 16:39:38 2007
@@ -21,10 +21,15 @@
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
+#include
#include
#inclu
andrzej zaborowski wrote:
> (the pixel format of the cursor was the same as the pixel format of
DisplayState).
I'm not sure if we want to always use the same pixel format - for
example with VMware SVGA and SDL in 16 bit mode, the cursor pixel
format reported by guest Xorg was 8 bpp. This would
> Now that the dust has settled, I see where the change is probably a
> no-op anyway. A quick little test program indicates that on x86_64,
> l_start will have an offset of 8 wether the structure is packed or not,
> and wether the __pad member is present or not. The unsigned long long is
> always g
On [Tue, 20.03.2007 19:05], Stuart Anderson wrote:
> Now that the dust has settled, I see where the change is probably a
> no-op anyway. A quick little test program indicates that on x86_64,
> l_start will have an offset of 8 wether the structure is packed or not,
> and wether the __pad member is p
On [Tue, 20.03.2007 21:47], Thiemo Seufer wrote:
> Stuart Anderson wrote:
> [snip]
> > --- linux-user/syscall_defs.h.orig 2007-02-23 15:44:47.0 -0500
> > +++ linux-user/syscall_defs.h 2007-02-23 15:44:26.0 -0500
> > @@ -1414,7 +1414,9 @@
> > struct target_eabi_flock64 {
> >
On Tue, 20 Mar 2007, Thiemo Seufer wrote:
Still, this part makes no sense to me since it is in a packed struct.
Can you explain why this works better for you?
It worked better, in that it fixed a problem that let me continue on to
fix other issues. After revisiting fcntl() and coming up with t
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/03/20 22:25:37
Modified files:
fpu: softfloat.c
Log message:
Ooops... Typo.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat.c?cvsroot=qemu&r1=1.5&r2=1.6
___
On Thursday 15 March 2007 14:53, Paul Brook wrote:
> > Subsequent releases of the branch would contain no functionality
> > enhancements, but just bug fixes, with the eventual aim of achieving
> > 'it just works' status for any x86/x86_64 guest I try to install/run.
> > I know that's a tall order,
Hi,
cpuid(01H) on i386 does not return the initial APIC id.
The following patch correct this.
Bernhard Kauer
Index: hw/apic.c
===
RCS file: /sources/qemu/qemu/hw/apic.c,v
retrieving revision 1.12
diff -u -r1.12 apic.c
--- hw/api
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/03/20 22:11:31
Modified files:
target-ppc : cpu.h exec.h op.c op_helper.c op_helper.h
op_mem.h op_template.h translate.c
translate_init.c
Log messa
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/03/20 22:10:42
Modified files:
fpu: softfloat-native.c softfloat-native.h
softfloat.c softfloat.h
Log message:
Add missing softfloat helpers.
CVSWeb URLs:
h
Stuart Anderson wrote:
[snip]
> --- linux-user/syscall_defs.h.orig2007-02-23 15:44:47.0 -0500
> +++ linux-user/syscall_defs.h 2007-02-23 15:44:26.0 -0500
> @@ -1414,7 +1414,9 @@
> struct target_eabi_flock64 {
> short l_type;
> short l_whence;
> +#if HOST_LONG_BITS
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/03/20 21:50:52
Modified files:
linux-user : syscall.c
Log message:
fcntl64 fix, by Kirill A. Shutemov.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=
> struct target_eabi_flock64 {
> short l_type;
> short l_whence;
> +#if HOST_LONG_BITS == 32
> int __pad;
> +#endif
This change is definitely wrong. This is a target structure, and is packed, so
should be independent of the host.
Paul
___
OK, I think I finally have it all sorted out. Sorry if I sounded dense
along the way.. there were multiple variable, which increases the number
of possible combinations quickly.
The patch from Kirill is needed, and makes things better. One thing I
notice with it is that we now handle TARGET_F_GE
On Tue, 20 Mar 2007, Kirill A. Shutemov wrote:
No. Remap is needed:
$ uname -m; echo -e '#include \nF_GETLK64' | cpp | tail -1
x86_64
5
$ uname -m; echo -e '#include \nF_GETLK64' | cpp | tail -1
armv5l
12
Same for F_SETLK64 and F_SETLKW64.
You are right. I had previously printed out the non
On [Tue, 20.03.2007 14:03], Stuart Anderson wrote:
> On Tue, 20 Mar 2007, Kirill A. Shutemov wrote:
>
> >>What are you using as a test app?
> >
> >I got error when runing Debian's apt-get and tried to fix it.
>
> OK, that's what got me started on this one, but I switched to using the
> ltp-kernel
Hi,
here is the patch which adds a "4KEcR1" CPU (a 4KEc, processor revision 2.2,
with MIPS32 Release 1 (!) instruction set is the heart of the AR7 SoC).
See also include/asm-mips/cpu.h in the Linux kernel sources:
./include/asm-mips/cpu.h:#define PRID_IMP_4KEC 0x8400
./include/asm-mips/c
On Tue, 20 Mar 2007, Kirill A. Shutemov wrote:
What are you using as a test app?
I got error when runing Debian's apt-get and tried to fix it.
OK, that's what got me started on this one, but I switched to using the
ltp-kernel-test package for a more comprehensive set of tests once I got
past
On [Tue, 20.03.2007 12:53], Stuart Anderson wrote:
> On Tue, 20 Mar 2007, Kirill A. Shutemov wrote:
>
> >>Kiril,
> >>What 32 bit host and 64 bit host are you using? I'm working on
> >>arm on x86_64, and I'm starting to think that perhaps all of the different
> >>parts of the fix are needed to
On Tue, 20 Mar 2007, Kirill A. Shutemov wrote:
Kiril,
What 32 bit host and 64 bit host are you using? I'm working on
arm on x86_64, and I'm starting to think that perhaps all of the different
parts of the fix are needed to ensure it works correctly on all target/host
combinations.
I'm
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/03/20 16:54:50
Modified files:
hw : slavio_timer.c
Log message:
SlavIO Counter-Timers fix, by Aurelien Jarno.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/slavio_time
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/03/20 16:52:54
Modified files:
hw : slavio_intctl.c
Log message:
SlavIO interrupt controller fix, by Aurelien Jarno.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/slav
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/03/20 16:45:27
Modified files:
. : Makefile.target vl.h
hw : pckbd.c ps2.c
Added files:
hw : vmmouse.c
Log message:
VMMouse Emulation, b
You may want to hit me with a brick :)
here is a draft not thested or whatever of kqemu-darwin.cpp before I
have to leave...
...just for some ideads.
/note to self
-open a folder in kju svn tonight, so that we don't have to spam
the list to much.
Mike
On 20.03.2007, at 12:58, Mike Krone
On 20/03/07, Anthony Liguori <[EMAIL PROTECTED]> wrote:
Thiemo Seufer wrote:
> andrzej zaborowski wrote:
>
>> This should allow the emulated video cards that support hardware
>> accelerated cursors to relay the cursor drawing to host, possibly
>> using real hardware cursor. This way the guest and
Thiemo Seufer wrote:
andrzej zaborowski wrote:
This should allow the emulated video cards that support hardware
accelerated cursors to relay the cursor drawing to host, possibly
using real hardware cursor. This way the guest and host effectively
share one cursor. Only SDL support is included.
andrzej zaborowski wrote:
> This should allow the emulated video cards that support hardware
> accelerated cursors to relay the cursor drawing to host, possibly
> using real hardware cursor. This way the guest and host effectively
> share one cursor. Only SDL support is included. Not tested with mi
"M. Warner Losh" <[EMAIL PROTECTED]> writes:
> Const does *NOT* imply that you don't own the memory. Its narrow
> meaning is just that the object won't be changed through this
> pointer/reference.
But free _does_ change the object.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE
In message: <[EMAIL PROTECTED]>
Anthony Liguori <[EMAIL PROTECTED]> writes:
: To me, const char * always implies that you don't own the memory. This
: is helped by the fact that free doesn't take a const void * and newer
: GCC's will complain if you free() a const char *.
Sadly, thi
On [Fri, 23.02.2007 16:58], Thiemo Seufer wrote:
> Kirill A. Shutemov wrote:
> > Fixed version of the patch in the attacment. Please, comment.
> [snip]
> > /* Look for path in emulation dir, otherwise return name. */
> > const char *path(const char *name)
> > {
> > +char *newname = (char *)
Thiemo Seufer wrote:
Anthony Liguori wrote:
Howdy,
The following patch adds an info serial and an info parallel command.
Besides providing useful information (especially for the serial port),
it provides a method for management tools to connect to a running VM and
what character devices
On [Tue, 20.03.2007 09:55], Stuart Anderson wrote:
>
> On Tue, 20 Mar 2007, Kirill A. Shutemov wrote:
>
> >Yep. You're right. Fixed patch in the attachment.
>
> Kiril,
> What 32 bit host and 64 bit host are you using? I'm working on
> arm on x86_64, and I'm starting to think that perhaps a
Here we go:
www.kronenberg.org/qemu/qemu-devel-darwin-kqemu-20mar07.tar.bz2
- Made a new IOKit kext proj to match all the kqemu name requirements
- moved kext header inside kqemu-darwin.cpp to lessen stray darwin
related files
- added kqemu-kernel.h to the target
- added kqemu.h to the target
Yep. You're right. Fixed patch in the attachment.
On [Mon, 19.03.2007 17:12], Thiemo Seufer wrote:
> Kirill A. Shutemov wrote:
> > TARGET_F_*64 should be used instead of F_*64, because on 64-bit host
> > systems F_GETLK == F_GETLK64(same for SETLK and SETLKW), so we cannot
> > determinate if it's
Alexander Voropay wrote:
> "Thiemo Seufer" <[EMAIL PROTECTED]> wrote:
>
> >For the AR7 case, could you
> >- add AR7 as a CPU type
> >- handle the interesting cases for AR7 only, after verifying the
> > cornercase behaviour of qemu and real hardware is consistent.
>
> AFAIK, Texas Instrument AR7
"Thiemo Seufer" <[EMAIL PROTECTED]> wrote:
For the AR7 case, could you
- add AR7 as a CPU type
- handle the interesting cases for AR7 only, after verifying the
cornercase behaviour of qemu and real hardware is consistent.
AFAIK, Texas Instrument AR7 isn't a CPU. It's a SoC which
combines wel
Cool :)
just dlded your tarball, and things work well.
I'm about to add the code to the "genuine" kqemu environment. With
kqemu Variables and function stubs.
I hope to post back soon.
Mike
On 20.03.2007, at 03:18, Philip Boulain wrote:
Mike Kronenberg wrote:
> So any suggestions on how t
41 matches
Mail list logo
